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

[Haruki Izumikawa <[e-mail]>]

Salvatore Loreto wrote:
> 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.

[HI] In fact, I don't assume the IMS. I simply consider the Internet. 
Given the IMS, a session continuity can be indeed performed. But, TMK, 
the 3GPP mobility management does not provide a fast/seamless handoff. 
The mobility management only provides a hard handoff. Is that correct?

Regarding HSDPA/LTE, as you pointed out, they can be enough to provide 
the realtime service to users. However, I also think that the available 
bandwidth per user might not become so high because a number of users 
simultaneously connect the same BS and radio resource is shared among 
the users...

I'm afraid the focus would move over a little. But anyway, thank you for 
the discussion.:-)

Best regards,

Haruki


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

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