Dear all, I am trying to summarize the feedback I have received so far, I would welcome your input if you see something missing, otherwise I will proceed updating the draft and then organize a call for people to comment live. So far (in addition to the authors of the draft), several people commented and expressed interest in joining the discussion: -- Salvatore Loreto, Cullen Jennings, Ashutosh Dutta, Serhad Doken and Hassnaa Moustafa -1- Cullen: add a mandatory requirement saying The solution should *allow* a "make before break" even if it is possible to use the solution to also do "break before make" -2- Cullen: add an optional requirement addressing packet loss (the general minimization of impairment is already a mandatory requirement) Using "make before break" should minimize packet loss. The solution should also try to take care of the packet reordering due to the vertical handover. -3- Serhad Doken: evaluate two additional requirements -- Vertical handover procedures not bringing down ANs --> I propose to add it (after re-wording) as "mandatory" -- MH not switching ANs too frequently --> I propose to add it as "optional desirable" -4- add an appendix describing recent work done in 3GPP at high level but still technically avoiding people to fetch 3GPP documentation: I will prepare text for this including VCC + Centralized IMS Service (latest evolution of VCC), Session Continuity Let me know if I missed or misinterpreted something. Cheers, Saverio ============================================================ Dr. Saverio Niccolini Manager, Real-Time Communications Group NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@xxxxxxxxxxxx <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On > Behalf Of Cullen Jennings > Sent: 23 January 2009 03:32 > To: Stefano Salsano > Cc: SIPPING LIST > Subject: Re: Comments on draft-niccolini-sipping-siphandover- > 05 > > > On Jan 18, 2009, at 23:16 , Stefano Salsano wrote: > > > Cullen Jennings wrote: > > > > > > I'd like it if the requirements state that the solution be able to > > > support a "make before break" style of handover even if it possible > > > to use the solution to also do "break before make". > > > > > > Cullen <in my individual contributor role> > > > > > Dear Cullen (and all interested people), > > > > we are revising the draft-niccolini-sipping-siphandover to take into > > account the different comments and I am now tackling your comment. > > > > We can simply take the comment literally, adding it in section 4: > > > > The solution should support a "make before break" even if it is > > possible > > to use the solution to also do "break before make" > > > > But if we dig a little bit into this problem... we can ask what is > > meant > > by "support": is it just "allow" or is it "exploit" ? > > > > > > My wording was pretty vague. I think the requirements should address > if the solution needs the make before break as mandatory to implement > and optional to use or if it is optional to use. I don't care too much > one way or the other. > > Therefore a second option is to include a mandatory requirement and > an > > optional one: > > > > > > > > Mandatory req: > > The solution should *allow* a "make before break" even if it is > > possible > > to use the solution to also do "break before make" > > > sure allow seems better > > > > > > Optional req: > > Using "make before break" should minimize packet loss. The solution > > should also try to take care of the packet reordering due to the > > vertical handover. > > > I agree we need text that gets to what does make before break even > mean from a requirements point of view so I like where you are going > here. > > In my ideal world, if the handover went from transport A, to transport > B, the end user perceived quality during the handover would be no > worse that whichever of A or B had the worst quality around the time > of the handover. It's not easy to translate that to crisp > requirements. I'm bascially looking for a solution where the media on > B is being received by the receiver before the sender stops sending on > A. > > > In this respect we had some discussion among contributors to the > > draft, > > > > salvatore loreto wrote: > > > how minimize the packet loss (or avoid it at all) and the re > > ordering > > > problem during a Vertical Handover! The question is there any > > > protocol solution that can avoid it, or it is an hacking question? > > > > I'd like to have some discussion and comments on this point: do we > > take > > care of requirements that relate to how the packets are handled in > > order > > to minimize loss and packet reordering ? > > > > Cheers, > > Stefano > > > > Cullen <in my individual contributor role> > > > > > > -- > > ******************************************************************* > > Stefano Salsano > > Dipartimento Ingegneria Elettronica > > Universita' di Roma "Tor Vergata" > > Via del Politecnico, 1 - 00133 Roma - ITALY > > > > http://netgroup.uniroma2.it/Stefano_Salsano/ > > > > E-mail : stefano.salsano@xxxxxxxxxxx > > Cell. : +39 320 4307310 > > Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 > > ******************************************************************* > > > > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip > Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
