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

From: [email-masked]
Date: Thu, 29 Mar 2001 12:50:26 -0600

Hi Hesham,

Please see my comments inline.

Br,
Zhigang
 
> 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 ?

To be fair, both sides gave their arguments for and against
HC context relocation. There is nothing proven yet (and so is 
the whole ideal of Wireless Mobile IP). In fact, people in ROHC
WG haven't spent much time debating on this because we didn't
want this debate to delay the delivery of the basic ROHC (we
had a very tight schedule).

Whether it is needed or not is a cost-benefit issue. From my 
point of view, the cost is small and the benefit is large. I
don't see reasons why we should not do it. But I'm willing to 
hear the arguments from the other side.

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

As I mentioned in my previous email, the issue is not only
the number of IR packets, it's the size of those IR packets.
Even if we are talking about 3 IR packets, the surge of bandwidth
required (e.g. 3*60 bytes vs. 3*5 bytes) is a heavy burden on
the radio links. If the HC context relocation can avoid this with
little cost, I don't see why we shouldn't do that.

(Side note: for hisorical and technical reasons, dealing with 
realtime VBR over radio links is much a headache than over wired 
links. )

> But either way it doesn't seem to be a problem since you 
> said that context relocation (if needed) will solve this. Right ?

I would say the huge (don't laugh at me, it's true) spike in
throughput over the radio link could be a problem. HC context 
relocation avoids it.

> So I don't know why we (MIP WG) should be involved. 
> It seems to be a ROHC/SEAMOBY issue. 

I'm not sure. The start of this thread seems to indicate the
opposite. But, I agree the context relocation is an issue 
dealt with in SEAMOBY (if I understand correctly).

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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Mar 2001 11:06:05 -0800 (PST)

> realtime VBR over radio links is much a headache than over wired 

   A-ha! That's one of the reasons I question whether
   ROHC is even appropriate on the air except in a
   very small subset of cases (usually long lived streams
   like RTP for which it was originally intended) As
   a general purpose tunnel/header compressor, I suspect it is going
   to have severe thrashing with the way that radio
   resources are doled out by the AP.

	     Mike

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 29 Mar 2001 23:38:59 +0200

>    resources are doled out by the AP.

I'm not sure why you are saying that (apart from the fact that we haven't
really done anything else but ROHC RTP yet).  How is ROHC worse than
uncompressed IP or 2507-compressed IP?

Gruesse, Carsten

---

From: Michael Thomas <[email-masked]>
Date: Thu, 29 Mar 2001 15:02:22 -0800 (PST)

> uncompressed IP or 2507-compressed IP?

Carsten,

My understanding about cellular traffic channels
-- and I would be happy to find out differently --
is that they do not deal well with variable rate
traffic well. This is unsurprising since they are
heavily optimized for voice traffic which has very
regular periodicity and payload sizes. DOCSIS
cable is somewhat similar (with which I'm much
more familar), and the fixed size slots cause
variable rate coders like CRTP and ROHC much grief
because the MAC scheduler does not have the
ability to occassionally allow larger packets in
real time on an unsolicited grant SID; if you
start a session with packets every 20ms with 80
bytes of payload, that's exactly what you get. If
you occasionally need to send 81 bytes, you cannot
send it on that traffic channel.

This presents a real problem for CRTP and ROHC
when they need to send full headers or first order
changes.  For this reason, the cable folks perform
what they call Payload Header Suppression instead.
Basically, it's just a first order compressor
which is always on (sorry, if I've got your
nomenclature mixed up). This obviously works, but
is not as efficient. Also, I have no idea how it
compares in robustness.

Now, it may be that the cellular MAC's and PHY's
need some retooling in the long run in which case
ROHC will work better, but if they work like I
think they do, it's going to be problematic in the
intervening time.

		Mike