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

From: [email-masked]
Date: Tue, 3 Apr 2001 23:15:33 -0500

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

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. 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]]
> 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]]
> > > 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]]
> > > >> 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/
> > > >>
> > > rk> ---
> > > rk> Mailing list for Robust Header Compression WG
> > > rk> Archive: http://www.cdt.luth.se/rohc/
> > >
> 
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>

---

From: "Phil Neumiller" <[email-masked]>
Date: Wed, 4 Apr 2001 03:56:32 -0500

Of coures I like make-before-break and Moore's law and run two
compressors in the MN and discard one when I no longer need it.

-pdn ;-)

----- Original Message ----- > Hello Tmima,