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

Hi Haruki,

of course make-before-break (setup a new a new TCP connection before 
tear down the  old one)  is  the right strategy,
I don't think will solve all the problems, you have to assure  not to  
loose any packets  and this is not so easy
just to mention a possible scenario some packets sent on the original 
TCP connection that need to be retransmit on the new one,
perhaps because during the handoff the quality channel was bed.

Some years ago during my PhD I have investigated a similar scenario in:
-G. De Marco, L. Barolli, S. Loreto "/Performance Analysis of IP 
Micro-mobility Protocols in Single and Simultaneous Movements Scenario/",
 The second International Symposium on Ubiquitous Intelligence and Smart 
Worlds (UISW2005)

regards
Sal

Haruki Izumikawa wrote:
> Dear Salvatore,
>
> > I completely agree with Paul, a SIP mobility solution should consider
> > also the MSRP and
> > in general TCP scenario.
> > In the voice or video scenario (using rtp) a few dropped packets could
> > be acceptable even
> > not noticed at all.
> > However using MSRP or in general TCP the scenario several issue should
> > be considered,
> > for example:
> > - the time to setup a new TCP connection (this especially in the
> > cellular world takes time several seconds)
> > - which messages or packets retransmit
> > - how avoid duplications or even retransmission of the same data
>
> Thank you for pointing out the controversial issues. I have recognized 
> the necessity and the importance of the support for the general TCP 
> scenario (incl. the MSRP). I just think that make-before-break 
> switching (handoff) can be one of the solutions to deal with duration 
> taken to setup a new TCP connection...  The other two should be also 
> solved in some way.
>
> Rgds,
>
> Haruki
>
>
>
> Salvatore Loreto wrote:
>> Paul Kyzivat wrote:
>>> Haruki Izumikawa wrote:
>>>  
>>>>  > And related to that - what about non-RTP media?
>>>>  > This same scenario is applicable to less conventional
>>>>  > media, such as IM. While technically it is possible
>>>>  > to follow the pattern you have outlined to establish
>>>>  > bicast MSRP, the identification of duplicate messages
>>>>  > will require a different solution.
>>>>
>>>> [HI] I think the bicasting solution is needed for realtime 
>>>> multimedia streams in which re-transmission cannot be acceptable. 
>>>> Therefore, I don't know some services such as IM or file transfer 
>>>> using MSRP need bicasting support. In fact, I haven't considered 
>>>> the concern you pointed out. I'm going to have to weigh this 
>>>> concern more carefully. Thank you for bringing this matter up.
>>>>     
>>>
>>> I guess it depends on what you mean by "acceptable".
>>> If you move from wifi to cellular access while IMing, I will not be 
>>> happy if some IMs from you are dropped or duplicated.
>>>
>>> In fact, I think this is more noticable for IM than for voice. With 
>>> voice a few dropped packets may cause a "glitch" but probably will 
>>> not create a significant loss of information. But a single dropped 
>>> IM can be a large loss of information.
>>>
>>> And now people are talking about using MSRP for real time text as well.
>>>
>>> So while it is perhaps of lower priority and interest, I think media 
>>> such as MSRP are worthy of some consideration.
>>>   
>> I completely agree with Paul, a SIP mobility solution should consider 
>> also the MSRP and
>> in general TCP scenario.
>> In the voice or video scenario (using rtp) a few dropped packets 
>> could be acceptable even
>> not noticed at all.
>> However using MSRP or in general TCP the scenario several issue 
>> should be considered,
>> for example:
>> - the time to setup a new TCP connection (this especially in the 
>> cellular world takes time several seconds)
>> - which messages or packets retransmit
>> - how avoid duplications or even retransmission of the same data
>>
>> regards
>> Sal
>