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

From: [email-masked]
Date: Fri, 6 Apr 2001 12:32:23 -0500

Hello,

> -----Original Message-----
> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 06, 2001 9:05 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
> 
> 
> 
> 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.
> 

If there is no compression state at the old router, why would you try to
relocate it ? 

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

Can you justify your claim above ?

>Trying to extend a point to point L2
> compression mechanism across an arbitrary internet
> is just *bizzare*. L2TP is bad enough.
> 

You are compressing IP and transport headers! This should work on ANY link.
That's why you try to CT header compression state. Get it ?

Regards,

-Rajeev

> 		Mike
> 
> [email-masked] writes:
>  > 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: Michael Thomas <[email-masked]>
Date: Fri, 6 Apr 2001 10:46:00 -0700 (PDT)

> If there is no compression state at the old router, why would you try to

   There's compression state there, but not the 
   compression state that matters: when I'm 
   receiving packets from the old AR during the
   FMIP transition time, there will be a *new*
   IP header appended toward the MN. This is
   because those packets will have to be tunneled to the
   MN. This means that it is a *new* compression
   context, not an old existing one.
 
 > Can you justify your claim above ?

   I can't prove negatives. I'm afraid that it
   is your place to prove that context transfer
   of header compression state in the face of all
   of these extenuating circumstances is still
   worthwhile.

 > That's why you try to CT header compression state. Get it ?

   Oh sure, I get it... I "get" VoMPLS too, but
   that doesn't make it any less bizarre.

	    Mike