Subject: Re: [Sipping] draft-niccolini-sipping-siphandover-05.txt

From: "Doken, Serhad" <[email-masked]>
Date: Tue, 13 Jan 2009 19:14:21 -0800

Saverio,

Additional requirements :

(a) Vertical handover should not put excessive load on the access network preventing it to serve existing MHs/sessions. For instance, multiple MHs in the 3G AN approaching a hot spot should not bring down a Wi-Fi network during/after the handover.

(b) MH should not ping pong between access networks during handover.

Terminal Mobility and Session Mobility can be intertwined. When two ANs are available to the MH, it may choose to keep the voice session in AN1 and handover the video to AN2 or move them both to AN2 and transfer the video part to another MH.

As a desirable requirement, splitting of signaling and media between different ANs may be possible.

Sec 2, within the description of Terminal mobility you mention IP subnets. I think you meant IP ANs unless you used in the sense of NATs.

Other comments :

First paragraph, "...access network can become not available anymore.." -> access network can become unavailable. 

Sec 2, network level mobility bullet, "...to recognize an available bandwidth" -> to recognize lack of bandwidth

Sec 3, "technologies and difference bandwidth/delay" -> "technologies and different bandwidth/delay"

Sec 4, "in the same moment" -> "..at the same moment"

Thanks,
Serhad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Saverio Niccolini
> Sent: Monday, November 24, 2008 8:56 AM
> To: [email-masked]
> Subject: Re: [Sipping] draft-niccolini-sipping-siphandover-05.txt
> 
> Dear all,
> 
> among the contributors it was discussed that is actually good to
> keep the discussion on the mailing list to gather more general
> feedback from everybody and more specific one from the people
> willing to actively contribute (people like John Elwell, Zaheduzzaman
> Sarker and Hassnaa Moustafa demonstrated interest in this).
> 
> So far we have received the following comments, that we are going to
> take care of:
> -- we should state clearly that terminal mobility has a requirement
> to 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",
> we should be able to formalize what "make before break" means
> at protocol level in a clear way to be able to write requirements
> for this
> -- provide more detailed summary of work in 3GPP to avoid people
> to look for and read the related 3GPP documents
> -- add an additional requirement that is to minimize the packet loss
> (or avoid it at all) and the reordering problem during an handover
> 
> What is still unclear:
> -- we should look at SIP-based terminal mobility requirement in general
> with vertical handover being one use case
> --> what are the requirements missing in the draft for looking at
> SIP-based terminal mobility requirement in general?
> 
> Any comments?
> 
> Thanks,
> 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
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Ashutosh Dutta
> > Sent: Monday, November 24, 2008 2:57 PM
> > To: Anton Tveretin
> > Cc: [email-masked]
> > Subject: Re: [Sipping] draft-niccolini-sipping-siphandover-05.txt
> >
> >
> > Anton Tveretin wrote:
> > > Dear All,
> > > Here is my contribution to the problem list. I hope this might help.
> > > 1. "Hanging TCP" problem: if, at the time of handover,
> > there is a TCP
> > > connection between nodes, this might cause sending packets to the
> > > wrong host (i.e. IP address of the MH changes, and previous IP is
> > > assigned to that host). This is also a security hole.
> >
> > Just a clarification. SIP-based terminal mobility could be
> > most useful for SIP-based sessions, where media is mostly
> > RTP/UDP (e.g., Interactive VoIP, RTP-based streaming). There
> > are additional complexities to support TCP-based application
> > (e.g., tcpchat) using SIP-based terminal mobility, although
> > not impossible. However, SIP-based terminal mobility cannot
> > be used for applications that are not initiated using SIP
> > signaling (e.g., FTP, Telnet).
> >
> > We had a draft discussing this issue a while back in 2001.
> >
> > http://www.argreenhouse.com/SIP-mobile/sip_draft4.
> >
> > One can potentially use any MIP-based solution to avoid such
> > complexity to support terminal mobility for TCP-based application.
> >
> > > 2. (Related to the previous): How can the CH find out that it is
> > > connected to the same host (MH), but with different IP address, and
> > > not something else? This is especially important for TLS
> > connections.
> > > 3. Handover collision problem, i.e. during handover process, the CH
> > > also changes its IP address. I don't see any solution for this
> > > problem. IMO the connection will be lost.
> >
> > Simultaneous mobility problem is a good one. There is
> > currently a draft in MEXT discussing this specific issue in
> > addition to few papers that have addressed this specific
> > issue. It also lists some of the solutions.
> > We should add this one as a requirement.
> >
> > http://tools.ietf.org/html/draft-wong-mext-simultaneous-ps-01
> >
> > Since we are discussing the requirement draft, we should not
> > be discussing possible solutions yet.
> >
> >
> > Thanks
> > Ashutosh
> >
> > > Sincerely yours.
> > > _______________________________________________
> > > 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
> > _______________________________________________
> > 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
> >
> _______________________________________________
> 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
_______________________________________________
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: Stefano Salsano <[email-masked]>
Date: Mon, 19 Jan 2009 07:05:42 +0100

Dear Serhad,

thank you for your valuable comments. We will take them into account in
the revision of the draft (we are now working to prepare the new version)

As discussed in the last WG meeting, we want to setup a design team of 
people interested to proceed in the definition of requirements. If you 
want to be involved or just be notified of the progress of the work, 
please contact Saverio or me.

Cheers,
Stefano

Doken, Serhad wrote:
> (a) Vertical handover should not put excessive load on the access
> network preventing it to serve existing MHs/sessions. For instance,
> multiple MHs in the 3G AN approaching a hot spot should not bring
> down a Wi-Fi network during/after the handover.
> 
> Terminal Mobility and Session Mobility can be intertwined. When two
> ANs are available to the MH, it may choose to keep the voice session
> in AN1 and handover the video to AN2 or move them both to AN2 and
> transfer the video part to another MH.
> 
> Sec 2, within the description of Terminal mobility you mention IP
> subnets. I think you meant IP ANs unless you used in the sense of
> NATs.
> 
> Other comments :
> 
> First paragraph, "...access network can become not available
> anymore.." -> access network can become unavailable.
> 
> Sec 2, network level mobility bullet, "...to recognize an available
> bandwidth" -> to recognize lack of bandwidth
> 
> Thanks, Serhad
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Saverio Niccolini 
>> Sent: Monday, November 24, 2008 8:56 AM To: [email-masked] 
>> willing to actively contribute (people like John Elwell,
>> Zaheduzzaman Sarker and Hassnaa Moustafa demonstrated interest in
>> this).
>> 
>> So far we have received the following comments, that we are going
>> to take care of: -- we should state clearly that terminal mobility
>> has a requirement to 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", we should be able to formalize what "make
>> before break" means at protocol level in a clear way to be able to
>> write requirements for this -- provide more detailed summary of
>> work in 3GPP to avoid people to look for and read the related 3GPP
>> documents -- add an additional requirement that is to minimize the
>> packet loss (or avoid it at all) and the reordering problem during
>> an handover
>> 
>> What is still unclear: -- we should look at SIP-based terminal
>> mobility requirement in general with vertical handover being one
>> use case --> what are the requirements missing in the draft for
>> looking at SIP-based terminal mobility requirement in general?
>> 
>> Any comments?
>> 
>> Thanks, 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
>> 
>> 
>> 
>>> -----Original Message----- From: [email-masked] 
>>> Sent: Monday, November 24, 2008 2:57 PM To: Anton Tveretin Cc:
>>> [email-masked] Subject: Re: [Sipping]
>>> draft-niccolini-sipping-siphandover-05.txt
>>> 
>>> 
>>> Anton Tveretin wrote:
>>>> Dear All, Here is my contribution to the problem list. I hope
>>>> this might help. 1. "Hanging TCP" problem: if, at the time of
>>>> handover,
>>> there is a TCP
>>>> connection between nodes, this might cause sending packets to
>>>> the wrong host (i.e. IP address of the MH changes, and previous
>>>> IP is assigned to that host). This is also a security hole.
>>> Just a clarification. SIP-based terminal mobility could be most
>>> useful for SIP-based sessions, where media is mostly RTP/UDP
>>> (e.g., Interactive VoIP, RTP-based streaming). There are
>>> additional complexities to support TCP-based application (e.g.,
>>> tcpchat) using SIP-based terminal mobility, although not
>>> impossible. However, SIP-based terminal mobility cannot be used
>>> for applications that are not initiated using SIP signaling
>>> (e.g., FTP, Telnet).
>>> 
>>>> 2. (Related to the previous): How can the CH find out that it
>>>> is connected to the same host (MH), but with different IP
>>>> address, and not something else? This is especially important
>>>> for TLS
>>> connections.
>>>> 3. Handover collision problem, i.e. during handover process,
>>>> the CH also changes its IP address. I don't see any solution
>>>> for this problem. IMO the connection will be lost.
>>> Simultaneous mobility problem is a good one. There is currently a
>>> draft in MEXT discussing this specific issue in addition to few
>>> papers that have addressed this specific issue. It also lists
>>> some of the solutions. We should add this one as a requirement.
>>> 
>>> Since we are discussing the requirement draft, we should not be
>>> discussing possible solutions yet.
>>> 
>>> 
>>> Thanks Ashutosh
>>> 
>>>> Sincerely yours. 
>>>> _______________________________________________ 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 
>>> _______________________________________________ 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
>>> 
>> _______________________________________________ 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
> _______________________________________________ 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
> 

-- 
*******************************************************************
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