Subject: RE: Reordering [was: Re: [rohc] Re: [tcpm] WG last-call of TCP headercompression]

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Thu, 29 Sep 2005 14:23:20 +0200

Mark, Joe,

since I spent a lot of work on the reordering draft,
there are some things that need to be added to the
conversation. See inline below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Mark West
> Sent: den 29 september 2005 13:38
> To: Joe Touch
> Cc: [email-masked]; Lars-Erik Jonsson (LU/EAB)
> Subject: Reordering [was: Re: [rohc] Re: [tcpm] WG last-call of TCP
> headercompression]
> 
> 
> 
> 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

Yes, that's easy to do, but not something that should be part
of any of the profile specifications. That should be a topic
for a ROHC-over-Foo document, IMO.

>   (2) optionally adding a fixed [large] number of bits to the MSN
>       encoding.

Unfortunately, it's not that easy. Packet-format wise, it is, but
like the reordering draft points out, the compressor needs to
be much more conservative when compressing fields that are
not LSB-encoded, and only change infrequently.

Normally, we use the optimistic approach to say which fields
that need to be encoded in a compressed header, but when you
have a change to some other field (let's say the URG is turned
in in mid-flow, you need to you need to transmit URG in "as
many packets as your worst-case reordering depth", and you
WILL lose some late arrivals unless you keep multiple context
copies at the decompressor (therefore my previous statement
that you lose a LOT of compression efficiency if you are to
handle arbitrary reordering depth).
We should say more on this in the spec (which I already
promised), but trying to handle this is not a good idea.
We should be clear on what we can do, and people who want
to use this on a long-reordering-rohc-channel should add
a external seq number via a draft-someone-rohc-over-foo.

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

Agreed.

/Kristofer

> 
> Cheers,
> 
> Mark.
> 
> 
> 
> 
> > Lars-Erik Jonsson (LU/EAB) wrote:
> > ...
> > >>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.
> >
> > 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.
> >
> 
> The MSN is LSB coded so could, in theory, vary.
> 
> > > 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.
> >
> > 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.
> >
> > >>>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.
> >
> > 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-
> > > 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.
> >
> > I don't understand how to NOT consider it a requirement if you're
> > running over IP.
> >
> > Joe
> >
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

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

...
> a external seq number via a draft-someone-rohc-over-foo.

That seems like a reasonable solution.

Joe