Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

From: [email-masked]
Date: Fri, 6 Apr 2001 10:52:51 -0500

Hi Gary,
 
No this is not bicasting. The path taken by the packets (during the context
establishment at the new compressor/decompressor) is as follows:

-------> Old compressor/decompressor ----------> New compressor/decompressor
-------------> MN
 
<------ Old compressor/decompressor <---------- New compressor/decompressor
<------------- MN
 
Khiem

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: Wednesday, April 04, 2001 8:47 AM
To: [email-masked]'; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6
Handover

Many real time context synchronization problems can be solved 
through "bi-casting", which is, I believe, the essence of what you 
describe. 

Gary 

> -----Original Message----- 
> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, April 04, 2001 12:16 AM 
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] 
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] 
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile 
> IPv6 Handover 
> 
> 
> Hello Tmima, 
> 
> Your idea is very similar to the one I had some time ago (refer to 
> http://www.cdt.luth.se/robhc/msg01274.html
<http://www.cdt.luth.se/robhc/msg01274.html> ). 
> 
> Essentially the idea is to relax the timing constraints and 
> allow some time 
> to establish the context at the new compressor/decompressor. 
> During that 
> context establishment time, the packets transit through the new 
> compressor/decompressor, but also transit through the old 
> which continues to 
> do compression/decompression. Once the context is 
> established, the new can 
> take over the compression/decompression process. 
> 
> The old compressor/decompressor helps the new compressor/decompressor 
> establish its context by sending some context information. 
> One way (as you 
> described, correct me if I am wrong) is to take a snapshot of 
> the context 
> and send it. To maintain context synchronization between the 
> old and new, 
> the new may do some update of the received context snapshot 
> to account for 
> the fact that the context may have been updated by the old 
> after it took the 
> snapshot. However, the problem is that packets may be lost 
> when sent from 
> the old to the new. So the new may do a context update based 
> on packet j, 
> but that update was not done by the old, since packet j was 
> never received 
> by the old. One way to solve this problem is to modify the 
> mechanism to send 
> the context information from old to new. Instead of sending a context 
> snapshot, the old sends the context-related information in 
> pieces, so the 
> new can gradually build up its context. This corresponds to the 
> Relocation-deferred-after-Link-Switching (RDLS)scheme in 
> http://www.cdt.luth.se/robhc/msg01274.html
<http://www.cdt.luth.se/robhc/msg01274.html> . You can look at 
> it for details. 
> 
> The case where the old takes a snapshot of its context and 
> sends to the new 
> for immediate transfer of compression/decompression role 
> corresponds to 
> Relocation-concurrent-with-Link-Switching (RCLS). 
> 
> RDLS addresses the timing problem in a very reliable manner, 
> but is more 
> complex than RCLS. It also requires a higher capacity 
> connection between the 
> old and new. So each approach has its pros and cons. 
> 
> In any case, I believe the context transfer (whether RCLS or RDLS) is 
> doable, and the advantages over brute force reinitialization over the 
> wireless link outweigh the costs. 
> 
> Khiem 
> 
> > -----Original Message----- 
> > From: ext Tmima Koren [ mailto:[email-masked] <mailto:[email-masked]>
] 
> > Sent: Tuesday, April 03, 2001 8:19 PM 
> > To: [email-masked]; [email-masked]; 
> > [email-masked] 
> > Cc: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked] 
> > Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor 
> on Mobile 
> > IPv6 Handover 
> > 
> > 
> > I wonder if it's possible to do both: 
> > The new router sends a request for context transfer, but 
> continues to 
> > forward the compressed packets to the old router, AND queues 
> > a copy of the 
> > packets he forwarded. Once he receives the context, the new 
> > router applies 
> > the necessary changes to the context from the queued 
> packets. Now his 
> > context is good and he can continue decompressing. 
> > Tmima 
> > 
> > At 07:58 PM 4/3/2001 -0500, [email-masked] wrote: 
> > > > -----Original Message----- 
> > > > From: ext Pete McCann [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > Sent: Tuesday, April 03, 2001 5:30 PM 
> > > > To: [email-masked] 
> > > > Cc: [email-masked]; [email-masked]; 
> > > > [email-masked]; [email-masked] 
> > > > Subject: RE: [seamoby] RE: [rohc] RE: Restarting 
> > Compressor on Mobile 
> > > > IPv6 Handover 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Yes, you would need to re-initialize the context over the 
> > air, but I 
> > > > don't think the bandwidth usage is high enough to matter.  In a 
> > > > wide-area cellular environment IP handoffs will be relatively 
> > > > infrequent.  The important consideration is the "glitch" 
> > experienced 
> > > > in voice traffic at handoff time, and this can be minimized by 
> > > > temporarily anchoring the compressor. 
> > > > 
> > > 
> > >I don't agree with you comments that you could ignore 
> > bandwidth usage and 
> > >assume infrequent handovers. 
> > > 
> > >a> 84 bytes of IPv6/UDP/RTP headers with Mobile-IPv6 Home 
> > Address option for 
> > >a voice payload of 20 - 30 bytes. Several such packets sent 
> > per each stream. 
> > > 
> > >b> With fast user mobility, each BTS/AP being a router, I 
> can imagine 
> > >frequent handovers. 
> > > 
> > >In any case, context relocation addresses a>, does not 
> > assume infrequent 
> > >handovers, as well as attempts to provide "glitch-free" 
> > voice. When the 
> > >context is already present at the target router before the 
> > MN starts sending 
> > >compressed packets, the application should not see the glitch. 
> > >I know there is work to be done here, so let's try to 
> focus on that! 
> > > 
> > >Regards, 
> > > 
> > >-Rajeev 
> > > 
> > > 
> > > > -Pete 
> > > > 
> > > > [email-masked] (rk) writes: 
> > > > 
> > > > rk> Hi, 
> > > > 
> > > > rk> How does this avoid the core problem of context 
> > > > rk> _re-initialization_ ? You would still need to send IR 
> > packets (to 
> > > > rk> new access router over the air interface) subsequent 
> > to handover 
> > > > rk> in order to start a new context..  Anchoring it at 
> > the previous 
> > > > rk> router may buy you some time, but not the bits.  I reckon 
> > > > rk> anchoring will bring its own set of problems. 
> > > > 
> > > > rk> Regards, 
> > > > 
> > > > rk> -Rajeev 
> > > > 
> > > > 
> > > > >> -----Original Message----- 
> > > > >> From: ext Pete McCann [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > >> Sent: Tuesday, April 03, 2001 11:32 AM 
> > > > >> To: [email-masked] 
> > > > >> Cc: [email-masked]; [email-masked]; 
> > > > >> [email-masked] 
> > > > >> Subject: RE: [seamoby] RE: [rohc] RE: Restarting 
> > > > Compressor on Mobile 
> > > > >> IPv6 Handover 
> > > > >> 
> > > > >> 
> > > > >> 
> > > > >> Hi, 
> > > > >> 
> > > > >> I think there is a simpler solution to this problem that 
> > > > most people 
> > > > >> are overlooking. 
> > > > >> 
> > > > >> It should be possible to keep the compressor/decompressor 
> > > > state at the 
> > > > >> old access router and to tunnel the already-compressed 
> > > > packets to and 
> > > > >> from the new access router.  Then the MN and new 
> > access router can 
> > > > >> renegotiate header compression state from scratch and take 
> > > > as long as 
> > > > >> they want to do so, because the MN is still getting 
> > service in the 
> > > > >> meantime. 
> > > > >> 
> > > > >> Someone earlier asked about support for ROHC on IP tunnels 
> > > > and I think 
> > > > >> this would be a good application for that. 
> > > > >> 
> > > > >> We are trying to move the mountain to Mohammed and I don't 
> > > > see why we 
> > > > >> can't do the reverse instead. 
> > > > >> 
> > > > >> -Pete 
> > > > >> 
> > > > >> 
> > > > >> --- 
> > > > >> Mailing list for Robust Header Compression WG 
> > > > >> Archive: http://www.cdt.luth.se/rohc/
<http://www.cdt.luth.se/rohc/>  
> > > > >> 
> > > > rk> --- 
> > > > rk> Mailing list for Robust Header Compression WG 
> > > > rk> Archive: http://www.cdt.luth.se/rohc/
<http://www.cdt.luth.se/rohc/>  
> > > > 
> > 
> > --- 
> > Mailing list for Robust Header Compression WG 
> > Archive: http://www.cdt.luth.se/rohc/ <http://www.cdt.luth.se/rohc/>  
> > 
>

---

From: "Phil Neumiller" <[email-masked]>
Date: Fri, 6 Apr 2001 11:02:30 -0500

I think Gary is right.  How is the compression relevant if it is acting
simply as a router?
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, April 06, 2001 10:52 AM
Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile IPv6 Handover

---

From: Michael Thomas <[email-masked]>
Date: Fri, 6 Apr 2001 09:04:59 -0700 (PDT)

Can somebody explain to me how this has any
possible applicability if you are using FMIP
during the transition? FMIP requires a new tunnel
for which there will be no compression state in
the old access router.

All of these interactions with MIP, FMIP, HMIP
etc, etc make it look to me like this is a losing
situation. It may be the better part of valor to
say that fast/smooth handoffs are inherently more
bandwidth consumptive and that one of the
casualties is header compression state in the mean
time. Trying to extend a point to point L2
compression mechanism across an arbitrary internet
is just *bizzare*. L2TP is bad enough.

		Mike