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

From: [email-masked]
Date: Thu, 29 Mar 2001 12:46:15 -0600

Hello Hesham,

> 
> Hello Zhiang, 
> 
> So it seems ot me that there is no clear consensus in ROHC
> on context relocation. Is that because the need is not proven ?
> 

I did not get this picture when reading Zhigang's e-mail. I believe he said
rohc had to attend the urgent matter of a draft for IP/UDP/RTP compression.
I guess the focus was on coming with a scheme that described the functioning
of an rohc compression mechanism that would also include context
initialization! Mobility, handover was perhaps outside the scope..

> I guess we need to know how bad a channel can be. I might 
> be completely wrong here but if we're only talking about 
> a couple of packets to sync the compressor, then context
> relocation seems to be an overkill. However, if the amount 
> of packets sent with full headers is significant, then I can 
> understand the need. 

I agree that we need a reasonable number. The number of packets needed to
initialize the context, it appears, can vary. I have heard 3 packets before,
but not two! The key issue is the compressor has to have "sufficient
confidence" according to rohc draft. The issue of confidence is critical
because of error conditions prevalent on cellular links. These errors could
be worse across cell boundaries during handovers. Furthermore, you have to
do context initialization for _each_ packet stream!

Also, I don't agree that context relocation is an overkill when few IR
packets are needed. Consider a channel optimized for sending 24 bytes of
voice payload and 4 bytes of header. Such CBR-like channels are common in
cellular, I gather. Now, if you have to send a header 84 bytes long
(IPv6/UDP/RTP + Home Address option), that is 3 voice packets. One approach
used to handle surges in bandwidth is to puncture bits in payload. If you
were to do that, you need to effectively live with the drop of 9 voice
packets (24 bytes of payload + 4 bytes of header) for 3 IR headers! This is
user-perceived disruption _due to context initialization_. 

> But either way it doesn't seem to be a problem since you 
> said that context relocation (if needed) will solve this. Right ?
> 
> So I don't know why we (MIP WG) should be involved. 
> It seems to be a ROHC/SEAMOBY issue. 
> 

Well, I think header compression context relocation is doable in seamoby. We
need some help from rohc in defining what a context is, say e.g.,
IPv6/UDP/RTP/voice-G.723.1. 

I guess MIP list is cross-listed because HMIPv6 is relying on rohc to
provide header compression support, which involves context initialization,
which in turn could be avoided during handovers using context relocation!

Regards,

-Rajeev

> Regards,
> Hesham
> 
> > -----Original Message-----
> > From:	[email-masked] [SMTP:[email-masked]]
> > Sent:	Friday, 30 March 2001 2:53
> > To:	[email-masked]; [email-masked]
> > Cc:	[email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > Subject:	RE: [rohc] RE: Restarting Compressor on Mobile 
> IPv6 Handover
> > 
> > Hi Claude,
> > 
> > Context relocation is useful regardless of the loss of 
> packets during 
> > handover as the bulk of the saving (of bytes over the radio 
> links) comes 
> > from the static header fields. For example, the new compressor (for
> > downlink) 
> > can jump start in FO state in stead of going through IR 
> state all over
> > again.
> > 
> > We have been studying HC context relocation since spring 
> 1999 (when we 
> > started ACE). Khiem has proposed text to ROHC list in June 2000 
> > (http://www.cdt.luth.se/robhc/msg00508.html). 
> Unfortunately, that item was 
> > not included in ROHC I-D, partially due to the urgency to 
> finish the basic
> > ROHC scheme (plus objections from some of the ROHC authors). 
> > 
> > Now, it's time we give it a serious look.
> > 
> > Br,
> > Zhigang
> > 
> > -----Original Message-----
> > From: ext Claude Castelluccia 
> [mailto:[email-masked]]
> > Sent: Thursday, March 29, 2001 1:40 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: Re: [rohc] RE: Restarting Compressor on Mobile 
> IPv6 Handover
> > 
> > 
> >   
> > Hello Zhigang, 
> > I seems from your email that context relocation will be 
> very useful for
> > RoHC. 
> > Is istalso the case if some packets are lost  when a MN 
> moves from one base
> > station 
> > to another one? 
> > In this case it is better to restart the context or relocate it? 
> > Do you know of any studies on this topic? 
> > thanks a lot! 
> > Claude. 
> > [email-masked] wrote: 
> > Hi, 
> >   
> >   
> > There are some guessing/assumptions behind the number (3-4). 
> > I'm not so sure that's always the case. The radio link condition 
> > before/after handover is likely be worse than normal condition. 
> > That may mean more packets could be lost (in this case, IR 
> packets). 
> > That will has impacts on the guessing of the number. 
> > Although we're talking about "very few" packets (be it 3-4 or 5-6), 
> > they are LARGE (40+ bytes for RTP/UDP/IPv4 headers and 60+ bytes 
> > for RTP/UDP/IPv6 headers). And most of the header fields 
> are static. 
> > That is the issue. With HC context relocation, there is no need to 
> > send the static fields over the air. The reduced overhead means 
> > less pain (e.g. delay, possible stealing or blanking of 
> voice payload). 
> > Note that smaller packets have lower chance to be hit by 
> transmission 
> > errors (even just one bit) and thus lost, assuming no link layer 
> > retransmission (which makes sense for real-time multimedia). 
> >  
> > -- 
> > 
> > ----------------------------------------
> > Claude CASTELLUCCIA, INRIA Rhone-Alpes  
> > ph:  +33 4.76.61.52.15 (fax: 52.52)
> > http://www.inrialpes.fr/planete/
> >   
> ---
> Mailing list for Robust Header Compression WG
> Archive: http://www.cdt.luth.se/rohc/
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Mar 2001 15:54:30 -0800 (PST)

Rajeev,

> user-perceived disruption _due to context initialization_. 

Are you aware of any quantitative analysis of the wire cost and delay's
involved in any proposed context relocation protocol?
I assume it doesn't come for free thus a comparison is needed between
context initialization and conext relocation.
(For instance, I think some of the context relocation protocols that 
were discussed in seamoby involved a roundtrip between the mobile and 
the old access router as well as between the mobile and the new 
access router which would add significant delay before the context is
relocated.)

  Erik