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

[Salvatore Loreto <[e-mail]>]

Haruki Izumikawa wrote:
> 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.
the handoff WLAN to cellular is a particular scenario,
if the scenario you have in mind is where the WLAN belong in somehow to 
the same operator of the cellular network then the 3GPP mobility 
management is already almost able to perform the handoff and the IMS 
subsystem provide you the session continuity.

if you are thinking of a scenario where the WLAN and the cellular are 
two totally different networks and you want use the cellular network as 
a simple pipe, then the situation is different and more complicate. 
However from a bandwidth point of view the performance of cellular 
network nowadays with HSDPA and in future with LTE are more then enough 
to provide the realtime service.

Sal

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

_______________________________________________
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