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

From: [email-masked]
Date: Tue, 3 Apr 2001 19:58:45 -0500

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

---

From: Tmima Koren <[email-masked]>
Date: Tue, 03 Apr 2001 18:18:59 -0700

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