Subject: RE: [rohc] Re: [tcpm] WG last-call of TCP header compression

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 29 Sep 2005 09:28:47 +0200

> > So, first of all, we have a document headed for publication on
> > the topic of rohc over reordering channels, so we should probably
> > add a reference to that and also describe some of the issues
> > for a compressor associated with reordering channels. That 
> I can add.
> 
> That'd be great.
> 
> > On the second issue of actually trying to handle "long reordering",
> > this will have a severe impact on compression efficiency however you
> > design your compression scheme, so I'd say that this should be
> > a separate profile that can be based on ROHC-TCP but use different
> > packet formats. We don't want to decrease the efficiency of the
> > case that we've been tasked to compress just to help a case that
> > seems more far-fetched.
> 
> Is there any reason the detection of reordering couldn't be automatic,
> i.e., using a longer field and using variable compression on 
> that field?

Now you are talking about pre-compressor reordering. Of course, such
reordering can easily be addressed by the compressor. When we talk
about troublesome reordering and header compression, we are usually
meaning compressor-decompressor reordering. For e.g. RFC 3095, the
assumption was that compressor-decompressor reordering could be avoided,
as we considered only links that could actually ensure in-order delivery.

> > It should also be noted that handling of reordering is not a part
> > of the requirements for this spec (RFC4163), so what we've done
> > actually surpasses the requirements, and since the requirements
> > have already been approved as an RFC, a change at this stage does
> > not seem like The Right Thing(tm).
> 
> Handling reordering is needed in some regard, since this works over IP
> which isn't ensured not to reorder.

Well, not really. ROHC usually works only below IP, as a link
optimization, and there it is often possible to avoid reordering. Pre-
compressor reordering can of course happen, but that can also easily be
handled by the compressor. The ability to tolerate significant compressor-
decompressor reordering, on the other hand, will degrade compression
performance, and has not been considered as a requirement for ROHC-TCP.

BR
/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2005 03:47:02 -0700

Lars-Erik Jonsson (LU/EAB) wrote:
...
> Now you are talking about pre-compressor reordering.

No - that shouldn't matter except in the efficiency of the compressor,
e.g., necessitating sending the uncompressed ID values.

What I'm thinking about is when reordering will cause the decompressor
to fail. Which can be used by the compressor to increase how many bits
of the MSN vary - i.e., treating a control field as lsb-compressible.

> Of course, such

Oh - those wouldn't be Internet links, then :-) Nothing at L3 can
'ensure' anything like this; L2 can ensure it by fiat, and L4 can ensure
it by reordering.

> optimization, and there it is often possible to avoid reordering. 

The term 'link' was bound to cause trouble, and here it is, IMO. This is
NOT a true link layer. It's a lot like a tunnel - it provides link
capability to the packets it carries (compresses), but runs over IP at L3.

You cannot 'avoid' reordering if you run over L3. You can detect it -
but only if your fields are large enough for any possible reorder - and
you can reestablish it.

> Pre-

I don't understand how to NOT consider it a requirement if you're
running over IP.

Joe

---

From: Mark West <[email-masked]>
Date: Thu, 29 Sep 2005 12:37:42 +0100 (BST)

Currently the only 'foo' for which 'ROHC over foo' is defined is PPP (RFC
3241 to be precise).  PPP, AFAIK, is not noted for re-ordering things...

ROHC itself can't run at L3 (no IP header!) and there's currently no way
defined to carry it over L3.  That's only as-of-this-moment, though:  so
see below...

The ROHC TCP requirements (which I think I pointed out in a reply to Kris;
maybe it went missing) state:

   4.  Note on misordering between compressor and decompressor:

       When compression is applied over tunnels, misordering often
       cannot be completely avoided.  The header compression scheme
       should not prohibit misordering between compressor and
       decompressor, as it would therefore not be applicable in many
       tunneling scenarios.  However, in the case of tunneling, it is
       usually possible to get misordering indications.  Therefore, the
       compression scheme does not have to support detection of
       misordering, but can assume that such information is available
       from lower layers when misordering occurs.

Basically, ROHC RTP historically assumed a non-reordering link-layer, but
we decided that this was too restrictive: people are likely to want to run
this over tunnels (there's a draft talking about ROHC-over-ipsec, for
example).

Again, as I mentioned in a previous mail:

- working out the ideal MSN encoding 'on-the-fly' to avoid problems sounds
like a fun post-graduate research project, but a bit hairy for ROHC RTP
:-)

- if you wanted to go beyond what's suggested by the requirement (i.e.
*if* we were to agree additional support for detecting re-ordering), then
that *could* be done by adding:
  (1) an [optional] external sequence number; or
  (2) optionally adding a fixed [large] number of bits to the MSN
      encoding.

But it's not clear whether this is necessary.  IPsec has a sequence
number.  If ROHC-over-IP is defined, it must be a requirement there there
is a sequence number, to cope with the fact that IP can re-order.  So
isn't it more a function of mapping ROHC to a link-layer, than of ROHC
itself..?

Cheers,

Mark.

> of the MSN vary - i.e., treating a control field as lsb-compressible.

The MSN is LSB coded so could, in theory, vary.

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2005 05:18:43 -0700

> 3241 to be precise).  PPP, AFAIK, is not noted for re-ordering things...

Understood, but *this* spec doesn't *require* that it be run over PPP,
and unless you either prohibit deployment over L2s that reorder, you
must at least detect when it exceeds your MSN.

> defined to carry it over L3.  That's only as-of-this-moment, though:  so

ROHC can run over L3 when it runs over an L2 encapsulated over L3
(L2VPN). And I didn't see anything that prohibited it running over an IP
tunnel (most usefully an IPsec tunnel, which is going to be hard to
compress TCP headers on otherwise, which I expect was the motivation for
the draft noted below).

>        from lower layers when misordering occurs.

What kind of misordering indications? That's what I expect the MSN to
verify, FWIW.

> like a fun post-graduate research project, but a bit hairy for ROHC RTP

That's fine.

> isn't it more a function of mapping ROHC to a link-layer, than of ROHC

You either need to be more clear about where this can be deployed, or
detect where it fails. IMO, it's safer to detect where it fails.

Joe