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

From: [email-masked]
Date: Thu, 29 Mar 2001 17:40:20 -0600

Hi Mike,

Your concern is very valid and has been looked into by ROHC WG.
Just a few clarifications:

1) The compressed header size will likely be 1 byte most of the time
(>90%). Then, some first order headers (3~5 bytes). Then, few full
header. As you said, how to send the last two types of packets is
non-trivial. But it is doable. For example, very large headers can
be handled by segmentation either at link layer of by ROHC itself
(see section 5.2.5 of ROHC-09).

2) I guess you're referring to TDMA radio. My understanding is that
CDMA may have a better handle on (slight) VBR.

IMHO, ROHC has done a good job to achieve both robustness and
efficiency. Let me rephrase Carsten's question this way: if 
ROHC is not "appropriate on the air", do you have better approaches
in mind?

Br,
Zhigang

> -----Original Message-----
> From: ext Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 5:02 PM
> To: Dr. Carsten Bormann
> Cc: Michael Thomas; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [seamoby] RE: [rohc] RE: Restarting Compressor on Mobile
> IPv6 Handover
> 
> 
> Dr. Carsten Bormann writes:
>  > >  > (Side note: for hisorical and technical reasons, dealing with
>  > >  > realtime VBR over radio links is much a headache than 
> over wired
>  > >  > links. )
>  > >
>  > >    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.
>  > 
>  > 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?
> 
> 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
>

---

From: [email-masked]
Date: Thu, 29 Mar 2001 19:36:03 -0600

Hi James,

Using the flow label (to identify a context) is certainly a good 
idea. I'm wondering if the ROHC CID (may need re-mapping during 
handover) can achieve the same goal. The former hinges on that the 
flow label is unique between the Access Router (AR) and the mobile 
node (MN) and remains constant when the MN attaches to a new AR 
(need re-negotiation if clashes with flow from other IP address?). 
The latter requires the mapping of old COA and the new one (details
unclear).

Somehow, I feel further thinking might be needed. On the other hand, 
they're not in conflict since the ROHC CID can be viewed as the 
result of hash function of the flow label. In addition, it could be 
a zero-bye CID (just for one flow) under the ROHC framework.

Br,
Zhigang

> From: ext James Kempf [mailto:[email-masked]]
> Sent: Thursday, March 29, 2001 6:15 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Zhigang,
> I agree that ROHC has done a good job and I don't want to imply by the
> following proposal that ROHC, perhaps modified to deal with context
> transfer and parameterized restart in IPv6, could not handle the
> problems with IPv6. This is just something I've been thinking about
> that might work if modifying ROHC is too difficult, or if the ROHC
> group has other priorities, like completing compression work on IPv4
> algorithms. Maybe it is completely unworkable in the end.
> 
> Assume that the Access Router and the mobile node could set up a 
> unique IPv6 flow label between them. This could also be done end to
> end with the corresponding node, if one wanted to preserve end to end
> semantics on the flow label.
> 
> Now, the Access Router can send exactly one packet with full header.
> The mobile node records the header and notes the flow label, as does
> the Access Router. After that, the Access Router strips the header and
> substitutes the flow label. Similarly in the uplink direction from
> the mobile node to the Access Router. If the flow label were 
> negotiated end to
> end, it might take more than one packet, but the negotiation only
> needs to be done once, and not every time the mobile node moves.
> 
> Since the flow label is 20 bits, the Access Router might want to hash
> the flow label to one byte rather than send the full flow 
> label across,
> since the Access Router knows the mobile node that is to get the flow.
> 
> When the mobile node moves to a new Access Router, the flow 
> label/header
> context is transferred via context transfer. The mobile node maintains
> the mapping. The new Access Router performs the same 
> stripping function, even 
> though the care of address has changed, as does the mobile node. 
> 
> Note that the compressor would still be needed for UDP/RTP headers.
> 
> If one doesn't want to use the flow label, a separately computed tag
> (like an MPLS label) could be used, based on the source address, but
> this would have to be recomputed if the corresponding node 
> were a mobile
> node and was changing its care of address. A flow label would remain
> constant.
> 
> Comments?
> 
> 		jak
>

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 16:14:52 -0800 (PST)

Zhigang,

the mobile node to the Access Router. If the flow label were negotiated end to

Since the flow label is 20 bits, the Access Router might want to hash
the flow label to one byte rather than send the full flow label across,
since the Access Router knows the mobile node that is to get the flow.

When the mobile node moves to a new Access Router, the flow label/header
context is transferred via context transfer. The mobile node maintains
the mapping. The new Access Router performs the same stripping function, even 
though the care of address has changed, as does the mobile node. 

If one doesn't want to use the flow label, a separately computed tag
(like an MPLS label) could be used, based on the source address, but
this would have to be recomputed if the corresponding node were a mobile
node and was changing its care of address. A flow label would remain
constant.

Comments?

		jak

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Fri, 30 Mar 2001 09:17:37 +0200

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

To be honest, we defined what is included in the context with the purpose to make context transfer easier. However, since context transfer is out of scope for header compression development (more of an issue for the environment where header compression is implemented), we did not do it in ROHC. It must be up to those implementing header compression in various environments to decide if it makes sense to them or not and, if it is desirable, to define how it should be done there.

/L-E

---

From: [email-masked]
Date: Fri, 30 Mar 2001 09:59:13 -0600

> However, since 
> context transfer is out of scope for header compression 
> development (snip)
>  
> /L-E

Why do you say that? Context transfer requires some new
signaling between the new and old compressor (decompressor).
The logic of ROHC also needs to be amended. Do you think
all of those should not be part of the protocol and just
an implementation issue? How about interoperability?

(The emails from other people seems indicating just the opposite.)

Zhigang