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

[Haruki Izumikawa <[e-mail]>]

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?

[1] Nakajima N., Dutta A., Das S., Schulzrinne H., "Handoff delay 
analysis and measurement for SIP based mobility in IPv6," ICC'03, 2003.

Best wishes,

Haruki


Mary Barnes wrote:
> And that document is sitting in the RFC editor's queue, so it is
> important to consider what additional requirements these other documents
> address beyond the ones in that document and the value of additional
> solutions beyond those already documented. 
> 
> Mary. 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, May 08, 2008 2:05 PM
> To: Saverio Niccolini
> Cc: SIPPING LIST
> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
> 
> Don't forget draft-shacham-sipping-session-mobility
> which I believe predates ther rest of your work.
> 
> 	Paul
> 
> Saverio Niccolini wrote:
>> Then my question is:
>> is SIP mobility something interesting to be investigated for the
> group?
>> I would like to stimulate discussion around this set of drafts:
>> http://www.ietf.org/internet-drafts/draft-izumikawa-sipping-sipbicast-
>> 01.txt
>> http://tools.ietf.org/html/draft-niccolini-sipping-siphandover-03
>> http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution
>>
>> It seems to me that they both address the same issue with similar 
>> scenarios in mind and similar requirements, in the end they differ for
> 
>> the technical solution proposed (as for the standardization 
>> requirements if it is an additional header we may need ot go to SIP, 
>> but if it is up to changing lines in SDP then it is MMUSIC)
>>
>> --> if we can get an agreement that the issues/scenario and common
>> set of requirements then this would be a good basis for discussion and
> 
>> we can rpoceed from there
>>
>> Anyone having an opinion on this?
>>
>> Cheers,
>> Saverio
>>
>> ============================================================
>> Dr. Saverio Niccolini
>> NEC Laboratories Europe, Network Research Division	
>> Kurfuerstenanlage 36, D-69115 Heidelberg
>> Tel.     [phone]
>> Fax:     [phone]
>> e-mail:  [e-mail] <-- !!! NEW ADDRESS !!!
>> ============================================================
>> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
>> London W3 6BL Registered in England 2832014
>>  
>>   
>>
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>>> Sent: Thursday, May 08, 2008 5:32 PM
>>> To: Haruki Izumikawa
>>> Cc: SIPPING LIST
>>> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
>>>
>>>
>>>
>>> Haruki Izumikawa wrote:
>>>> Dear Stefano,
>>>>
>>>> Thank you for your interest. I have reviewed your updated
>>> I-Ds. As you
>>>> pointed, I also think that we share common requirements and
>>> scenarios.
>>>> I understand the addition of a new SIP header could not be a major 
>>>> concern. In fact, I have proposed a new SIP header for
>>> bicasting before.
>>>> But, I'm afraid that the addition of a new SIP header falls
>>> into terms
>>>> of reference of SIP WG, not SIPPING WG. How do you feel about it?
>>> That is true. But the work could and should start in SIPPING. 
>>> If it eventually is decided that a new header is needed then that 
>>> work would be shifted to the SIP WG with blessings from SIPPING. 
>>> Since there is a huge overlap in participation that should not cause 
>>> any difficulty.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> Best wishes,
>>>>
>>>> Haruki
>>>>
>>>>
>>>> Stefano Salsano wrote:
>>>>> Dear Haruki,
>>>>>
>>>>> thank you for restarting discussion on SIP mobility. I
>>> agree with the
>>>>> importance to discuss this topic in this WG.
>>>>>
>>>>> I'd like to bring again to the attention of the WG two related 
>>>>> internet drafts that we submitted some time ago and that we've now 
>>>>> updated
>>>>>
>>>>> [1] Requirements for vertical handover of multimedia
>>> sessions using
>>>>> SIP
>>>>> http://tools.ietf.org/html/draft-niccolini-sipping-siphandover-03
>>>>>
>>>>> [2] A solution for vertical handover of multimedia
>>> sessions using SIP
>>> http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution
>>>>> -02
>>>>>
>>>>> Now I would like in particular to focus on the
>>> requirements draft [1]
>>>>> and to make some comparison with your work.
>>>>>
>>>>> It seems that the requirements and scenarios we consider
>>> are largely
>>>>> overlapping (while we take different approaches for solutions).
>>>>>
>>>>> We have in common the idea of letting the Correspondant
>>> Node as much
>>>>> as possible not involved in the seamless handover
>>> procedure and the
>>>>> introduction of some sort of B2BUA to assist in the procedure. We 
>>>>> also share the idea that bi-casting can improve the handover and 
>>>>> needs to be properly managed.
>>>>>
>>>>> As you have already outlined in your draft, a difference in the 
>>>>> requirements is that you would like not to introduce new 
>>>>> headers/parameters while we allow it.
>>>>>
>>>>> My point here is that the introduction of the new headers in our 
>>>>> scenario only concerns the handover-capable mobile device and the 
>>>>> intermediate element which is in charge to assist in the handover 
>>>>> procedure. Correspondant Node and all other SIP elements are not 
>>>>> touched anyhow. I feel that in any case there the need to
>>> implement a
>>>>> lot of specicif logic to properly handle the bi-casting (not to 
>>>>> mention the problem of discovery of intermediate element that you 
>>>>> deliberately neglect in your draft to simplify the problem).
>>>>> Therefore the addition of a new header may not be the
>>> biggest issue.
>>>>> Anyway these aspects could be clarified with some deeper technical 
>>>>> discussion, which I hope can start in the WG.
>>>>>
>>>>> Best regards,
>>>>> Stefano
>>>>>
>>>>> Haruki Izumikawa wrote:
>>>>>> Hello folks,
>>>>>>
>>>>>> I'd like to have an open discussion about SIP-based
>>> mobility in this ML.
>>>>>> Mobility managements using SIP have been actively studied and 
>>>>>> developed worldwide since "Mobility Support Using SIP"
>>> (by Elin and
>>>>>> Henning) was published. SIP-based mobility would have strong 
>>>>>> advantages such as its great affinity for an application
>>> as well as
>>>>>> flexibility, i.e., terminal mobility can be optimally
>>> supported independent from underlying network.
>>>>>> On the other hand, despite many advantages, it is not used for 
>>>>>> large-scale commercial yet. In addition, the discussion about 
>>>>>> SIP-based mobility in IETF seems to be undynamic.
>>>>>> These days, a multimode terminal is getting popular. Each access 
>>>>>> networks, e.g., cellular and WLAN, have different
>>> characteristics in
>>>>>> terms of throughput or delay. In such a heterogeneous
>>> network, SIP
>>>>>> becomes more useful tool for mobility management because of its 
>>>>>> flexibility. The quality of a multimedia service can be
>>> adaptively
>>>>>> changed in accordance with a nature of an access networks
>>> even after
>>>>>> changing an access network. I think it is time to resume
>>> discussing
>>>>>> about SIP-based mobility. For your information, I have
>>> submitted I-D
>>>>>> regarding seamless session handoff by SIP-based bicasting.
>>>>>>
>>> http://www.ietf.org/internet-drafts/draft-izumikawa-sipping-sipbicas
>>>>>> t-01.txt
>>>>>>
>>>>>> I would be happy to hear frank opinions of SIP specialists.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Haruki
>>>>>>
>>>>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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