Re: [Sipping] Request for Open discussion about SIP mobility

[Haruki Izumikawa <[e-mail]>]

Salvatore Loreto wrote:
> I agree with the fact that network and application layer mobility may 
> have different roles and utilizations.
> Of course MIP/MIPv6 make the terminal mobility transparent at the 
> application level, however they introduce
> a latency (a path not optimized)  that could be avoided using the 
> mobility at the application level
> 
> About the needs to recognize the available bandwidth and delay before or 
> during the handoff,
> I think it is not a big problem and it could be resolved even also right 
> after the handoff with a re-invite.
> Am I wrong in that?

[HI] Personally, I think it is important to recognize the available 
bandwidth and delay and make an accommodation with a target NW in 
advance for an enhancement of users' QoE. Realtime services, especially 
bi-directional realtime services that is much delay sensitive, could be 
interrupted right after handoff, e.g. from WLAN to cellular, because of 
such as a lack of bandwidth if a new media information is updated by a 
re-invite after the handoff.
Though I'm not sure I'm right or not, I believe that an affinity for 
applications is one of the merits of application layer mobility.

Rgds,

Haruki

> 
> Sal
> 
> 
> 
> Haruki Izumikawa wrote:
>>  > In the case of IPv6 I know there are limits to where IP
>>  > addresses can be connected. And there is mobile IPv6.
>>  > So there the question may be "why won't IPv6 mobility
>>  > be enough to preserve you sip and media sessions as
>>  > you move from one access network to another?"
>>
>> [HI] I know the advantages of network-level mobility since I had studied 
>> MIP/MIPv6 for years. One of the merits of MIP should be making the 
>> mobility of a terminal transparent to an application by keeping the same 
>> IP address. This scheme is useful to run existing applications. I think 
>> MIP is enough technology to deal with the mobility only when a handoff 
>> occurs in homogeneous network and non-realtime application is used.
>>
>> However, MIP has limitations in my view. For example, an available 
>> bandwidth and delay may well differ significantly among heterogeneous 
>> networks, such as wireless LAN and cellular. So, I think an application, 
>> especially a realtime application, needs to recognize, for example, an 
>> available bandwidth and delay before or during handoff to adjust a 
>> transmitting rate or buffer space to a target network. Since MIP makes 
>> the mobility transparent to the upper layer, it is difficult to do it. 
>> And, the realtime stream can be aborted or interrupted just after handoff.
>>
>> On the other hand, SIP has an affinity for applications, which can make 
>> handoff more flexible. So I believe that SIP is worth discussing as a 
>> technique to support the terminal mobility for a terminal that runs a 
>> realtime application in heterogeneous networks.
>>
>> In my view, both network and application layer mobility are necessary, 
>> and they have different roles.
>>
>> I would be happy to hear views of many.
>>
>> Regards,
>>
>> Haruki
>>
>>
>> Paul Kyzivat wrote:
>>   
>>> Stefano Salsano wrote:
>>>     
>>>> Paul Kyzivat wrote:
>>>>       
>>>>> I'll try to channel Henry for a moment, and ask why we need to do 
>>>>> *anything* at the sip level to handle a device moving from one IP access 
>>>>> network to another.
>>>>>         
>>>> Dear Paul,
>>>>
>>>> I think that SIP is already concerned with "devices moving from one IP 
>>>> access network to another".
>>>> The re-INVITE mechanisms already described in current SIP RFCs allows to 
>>>> support terminal mobility, taking care of "devices moving from one IP 
>>>> access network to another".
>>>>       
>>> Sip can do lots of things, many of which are probably a bad idea.
>>>
>>> I said I was channeling Henry here, and I will continue for a bit, 
>>> playing the devil's advocate.
>>>
>>> Why would you want to establish a new sip signaling path just because 
>>> you have chosen to use a new access network? *Why* won't the IP address 
>>> you were using with the first access network continue to work with the 
>>> new access network?
>>>
>>> (I'm sure there are answers to this, but perhaps they need to be flushed 
>>> out.)
>>>
>>> In the case of IPv6 I know there are limits to where IP addresses can be 
>>> connected. And there is mobile IPv6. So there the question may be "why 
>>> won't IPv6 mobility be enough to preserve you sip and media sessions as 
>>> you move from one access network to another?"
>>>
>>> It would seem that often the answer is that the operators of the access 
>>> networks insist on participating at the application protocol level so 
>>> that they can charge more and avoid being commoditized, even if what we 
>>> really need are some good commodity IP access networks. Having been 
>>> locked out of participating in HTTP they want to avoid repeating that 
>>> situation with SIP.
>>>
>>> 	Paul
>>>
>>>     
>>>> The point is: do we think that this already defined re-INVITE mechanism 
>>>> suits all the requirements for having a SIP based terminal mobility ?
>>>>
>>>> In my opinion there at least two big issues with the current mechanism, 
>>>> that could deserve the investigation of additional requirements and 
>>>> solutions:
>>>>
>>>> 1) The responsibility for supporting the mobility of a Mobile Node (MN) 
>>>> is assigned to the Corresponding Node (CN). If the CN does not support 
>>>> (or does not support well) the re-INVITES you cannot offer a reliable 
>>>> mobility service using SIP. If you are an enterprise and you want to 
>>>> offer to your employees a SIP based mobility service supporting 
>>>> handovers you have to be sure that the procedure works well 
>>>> independently from the remote CN you are talking (not to talk if you are 
>>>> a service provider and you are selling a SIP based mobility services...)
>>>>
>>>> 2) Performance issues: the current solution is not very well suited for 
>>>> a seamless handover, comparable in performance with cellular networks. 
>>>> Mechanisms like bi-casting could improve the performance.
>>>>
>>>> Comments are welcome!
>>>>
>>>> Best regards,
>>>> Stefano
>>>>
>>>>       
>>>>> Ashutosh Dutta wrote:
>>>>>         
>>>>>> Haruki,
>>>>>>        I would actually put Shacham et al.'s draft into session mobility 
>>>>>> category rather than service mobility since it involves transferring an 
>>>>>> existing session from one device to another device. While there is a 
>>>>>> need for fast session transfer between devices, fast-handoff for 
>>>>>> SIP-based terminal mobility needs to be looked into as well, where the 
>>>>>> existing session continues on the same device after the handoff (the 
>>>>>> device could be single homed or multi-homed).
>>>>>>
>>>>>> Realizing the need for fast-handoff for SIP-based terminal mobility, 
>>>>>> subsequent to the paper that you had cited below, we did publish few 
>>>>>> other papers later on that looked into some possibilities of supporting 
>>>>>> fast-handoff for SIP-based terminal mobility. Let me cite those below. I 
>>>>>> am also aware of few other papers supporting SIP-based terminal mobility 
>>>>>> and fast-handoff as well.
>>>>>>
>>>>>> 1) A. Dutta, S.Madhani, H. Schulzrinne, O. Altintas, W. Chen, "Optimized 
>>>>>> Fast-handoff Schemes for Application Layer Mobility Management,"  ACM 
>>>>>> MC2R November 2002
>>>>>>
>>>>>> 2) P-Y Hsieh, A. Dutta, H. Schulzrinne,  "Application Layer Mobility 
>>>>>> Proxy for Real-time communication," 3G Wireless 2003, San Francisco, CA
>>>>>>
>>>>>> 3) A. Dutta, S. Madhani, W. Chen, O. Altintas, H. Schulzrinne, 
>>>>>> "Fast-handoff Schemes for Application Layer Mobility Management," PIMRC 
>>>>>> 2004, Barcelona, Spain
>>>>>>
>>>>>>
>>>>>> While there are variations of fast-handoff techniques for network layer 
>>>>>> mobility (e.g., FMIPV6, HMIPv6, FPMIPv6), I think it is probably a good 
>>>>>> idea to investigate if existing techniques can support fast-handoff for 
>>>>>> SIP-based terminal mobility. This need becomes more apparent if a 
>>>>>> carrier or any application service provider does not want to deploy any 
>>>>>> MIP variants to support purely SIP-based applications.
>>>>>>
>>>>>> Regards
>>>>>> Ashutosh
>>>>>>
>>>>>> Haruki Izumikawa wrote:
>>>>>>           
>>>>>>> I agree with the Mary's comment. It should be important to clarify 
>>>>>>> differences between Shacham's I-D and other I-Ds related to SIP mobility.
>>>>>>> I understand that main difference between them is their focus. While 
>>>>>>> Shacham's I-D is regarding "service mobility", Niccolini's or my I-D 
>>>>>>> are regarding "terminal mobility". According to the Dutta's previous 
>>>>>>> paper [1] regarding a terminal mobility using SIP, a handoff delay of 
>>>>>>> media packet could be at least around several hundred msec even if the 
>>>>>>> handoff is executed between homogeneous networks. Such service 
>>>>>>> disruption cannot be acceptable for real-time multimedia 
>>>>>>> communications. Indeed, the minimization of the service disruption 
>>>>>>> during the session transfer appears on the Shacham's I-D as one of the 
>>>>>>> requirement. Yet, its solution seems not to be found in the I-D. This 
>>>>>>> could be because the service disruption is not so critical in the 
>>>>>>> service mobility since the device itself is changed in the service 
>>>>>>> mobility and a user does not take it so seriously. However, to 
>>>>>>> minimize the service disruption should be high-priority for the 
>>>>>>> terminal mobility.
>>>>>>> Therefore, I think it is necessary to consider the solution to 
>>>>>>> minimize the service disruption during handoff. So what do you think?
>>>>>>>
>>>>>>>             
>>> _______________________________________________
>>> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use [e-mail] for questions on current sip
>>> Use [e-mail] for new developments of core SIP
>>>
>>>     
>>
>>   
> 

-- 
Haruki Izumikawa
KDDI R&D Laboratories

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP