Subject: Re: [Sipping] Comments on draft-niccolini-sipping-siphandover-05

From: Stefano Salsano <[email-masked]>
Date: Mon, 19 Jan 2009 07:16:33 +0100

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" ?

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"

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.

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

-- 
*******************************************************************
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  : [email-masked]
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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Jan 2009 19:31:55 -0700

> 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.
> to use the solution to also do "break before make"
sure allow seems better
> should also try to take care of the packet reordering due to the
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.

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 26 Jan 2009 15:57:23 +0100

Cullen,

> B is being received by the receiver before the sender stops sending on

The first mandatory requirement in the draft says:

The solution should take care of handover as fast as possible.
The goal is to provide a "seamless" handover with no perception
from the user point of view.

Is this what you are referring to, or would you like to see specific 
text related to the "make before break" way of doing handover?

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:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 26 Jan 2009 16:11:58 +0100

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: 23 January 2009 03:32
> To: Stefano Salsano
> Cc: SIPPING LIST
> Subject: Re: [Sipping] Comments on draft-niccolini-sipping-siphandover-
> 05
> 
> 
> On Jan 18, 2009, at 23:16 , Stefano Salsano wrote:
> 
> > Cullen Jennings wrote:
> > >