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

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

> > However, that is not a very constructive way of
> > arguing. When we discussed this last time on the rohc list,
> > we ended up agreeing that setting IP-ID to 0 could be
> > considered legal when DF is set.
> 
> The ROHC group doesn't get to make that decision; you need to override
> RFC791 as per above first with a standards-track mod to 791.

Well, neither can the ROHC WG judge what is really right or
wrong here. We see that some stack implementers have interpreted
791 differently and generates IP-ID set to zero when DF is set, and
several ROHC implementers have raised this as a problem due to the
reduced compression efficiency it causes for RFC 3095 (where we did
not consider such an IP-ID assignment).

I still can not see why we should not consider this behavior in
our compression profiles, when it is a behavior we see out there.

Cheers,
/L-E

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

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Sep 2005 00:29:20 -0700

> our compression profiles, when it is a behavior we see out there.

ROHC is incorrect in specifying compressibility of a noncompliant IP packet.

Or do you compress corrupted packets? You see those too.

I.e., unless your goal is to change the existing spec, it's better to
avoid the issue and declare that IP ID is either sequential,
sequential-jump, or random. There's no reason to accomodate bugs with
enhanced compression, or to validate buggy implementations by even
mentioning them, except as a bug, i.e.,

"implementations that use a constant, unchanging IP ID have been noted,
but are not be treated separately as compressable because this use is
not known to be RFC791 compliant."

Joe

---

From: Mark West <[email-masked]>
Date: Wed, 28 Sep 2005 11:42:17 +0100 (BST)

Joe,

Of all the [many] controversies I was expecting, this was *way* under my
radar ;-)

Still...

> Or do you compress corrupted packets? You see those too.

If you'll accept a slightly narrower question of 'do we compress packets
that the receiving end-host will reject?' then the answer is assuredly
'yes'.  Validating or rejecting e2e TCP/IP packets is up to end-systems.
RoHC is transparent.  (Yup, we had that argument too, way back when...)

RoHC will not mirror TCP state -- we neither know nor care if the seqno is
out of the window, for example.

And practically no checks are done of IP headers (e.g. RoHC does not
filter multicast source addresses).  RoHC is *not* (nor does it contain)
an IP stack, so does not itself embody the rules of RFC 791 / RFC 1122.

You'll find equally little verification in RFC 1144, BTW.

[see also section 3.1 and footnote 9 of RFC 1144 w.r.t. the discussion of
IP header checksum regeneration...]

I accept that there's a difference between 'passing transparently' and
'compressing efficiently' but, FWIW:

- We try to handle things (reserved bits, unknown options) efficiently so
that RoHC TCP performance degrades gracefully over time.  Like it or not,
his suggests not being limited by strict adherence to current specs.

- Zero (strictly: constant) IP IDs can be compressed by RFC 1144, RFC 2507
and RFC 3843 (at least) -- all of which can be used to compress TCP flows.

Cheers,

Mark.

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Sep 2005 08:06:02 -0700

> RoHC is transparent.  (Yup, we had that argument too, way back when...)

Fair enough all around. However,

...
> and RFC 3843 (at least) -- all of which can be used to compress TCP flows.

The fact that these bugs weren't caught by the IESG or cross-area is
disappointing, but it remains.

I appreciate that you don't validate the packet - i.e., check whether IP
ID is zero - but it seems entirely out of scope to design a compressor
to accomodate that bug.

It's simple enough to omit it. I appreciate that this isn't what has
been done before, but that's not an excuse to continue to err.

Joe