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

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Wed, 28 Sep 2005 11:07:06 +0200

Hi Joe!

Some more comments below.
I've edited out the points where we seem to have agreement or
are very minor.
I'm also leaving out the IPID-zero-discussion since that's 
discussed in a separate thread.

> 
> Using even both 'link' and 'channel' is confusing - it'd be preferable
> to create an inclusive definition and use one afterwards throughout.
> 

A channel means a ROHC channel, which is something very different to
a link. We'll try to be a bit more clear with either the references
to other docs or add something to the terminology for the next revision.

> >>end of that same paragraph, MSN applies only for flows with <= 2^16
> >>packets in flight throughout the connection - the MSN does 
> _NOT_ wrap
> >>the way the TCP number does. This will be a problem for high speed
> >>connections - even for 1500byte packets, a connection on a 
> 1Gbps link
> >>needs to run only 1 second to wrap MSN and break things... or am I
> >>missing something?
> > 
> > Well, ROHC isn't really targetting 1Gbps speeds, it's more 
> targeted at
> > cellular links, so wrap has not been considered an issue.
> 
> This would necessitate clear statement up front and in the 
> abstract that
> the intended use is slow links - which I didn't see. Given that, we
> can't know where this will be used. We need to either detect and avoid
> wrap, or accomodate it. This doc needs to do one of the two.
> 

Ok, I'll try to add a short section on "how to use ROHC-TCP on
high-speed and/or high-delay ROHC channels".
Maybe also something to the abstract regarding the main target.

> >>- - 6.4.1, 6.4.2, etc. regarding 'not sending' checksums, but rather
> >>recomputing them on the receiver side; I'm presuming that these are
> >>validated somewhere the compressor before being sent, but it's not
> >>clear. compressors can live at hosts, routers, or just 'bump in the
> >>wire'. the last one bothers me, since the input could have been
> >>corrupted, and this will ignore the error and just send a 
> >>valid checksum
> >>for whatever header fields are received. IMO, a compressor 
> that omits
> >>the checksum MUST do two things:
> >>	- ensure that the checksum was checked in the compressor side
> >>	either just before the compressor or inside it
> >>	- cover the fields that were protected by the checksum by
> >>	some other checksum that is at least as strong, either in
> >>	whole or in parts (e.g., CRC the state packets AND CRC the
> >>	deltas sent)
> >>This needs to be discussed more explicitly.
> > 
> > This behavior is also inherited from 3095, where these 
> fields are treated
> > the same way. The motivation for the IPv4 header checksum 
> can be found
> > there (page 156). Since all compressed packets are 
> protected by a CRC
> > over the uncompressed packet, these checksums cover only a 
> subset of the
> > ROHC CRC.
> 
> Aargh! If the answer to a question about checksums is contained in the
> _appendix_ of a multi-hundred page document, something's 
> broken! First,
> that needs to be reiterated here, even if to cite the other. Second, I
> disagree with the other doc for the reasons above, which the other doc
> doesn't discuss.
> 
> I agree that this won't affect correct operation, but it's 
> not clear why
> the decision was made in a way that could end up compressing corrupted
> packets needlessly. That needs to be addressed *here*.
> 

I discussed this with two of my co-authors, and we feel that the
current solution is the way to handle this.
_I_ think that we could add a couple of sentences of motivation
and possibly short text to say that the compressor MAY/SHOULD/MUST
verify these checksums before deciding to compress such packets.
I'll discuss this further with the other authors, though.

> >>- - sec 8.1 if the MSN is only 4 bits, how will you ever 
> >>detect that the
> >>reordering is larger than 16 packets? i.e., there appears 
> to be no way
> >>to detect an error that violates this assumption. I thought 
> >>that the MSN
> >>would protect us from that sort of thing, and your 
> compression thereof
> >>seems to defeat that purpose. IMO, MSN can't be smaller than 
> >>the number
> >>of packets in the RTT between compressor and decompressor, 
> >>and can't be
> >>compressed for exactly this reason.
> > 
> > The design is to only handle very few packets of reordering (the LSB
> > offset of 3 means a packet can only arrive "three packets late").
> > Remember that this is reordering between the compressor and 
> decompressor
> > and not end-to-end reordering, which is always handled by 
> the compressor.
> > 
> > Packets that arrive "too late" will be caught by the CRC, 
> or the feedback
> > or periodic repetition will repair the context quite soon.
> > 
> > We could possibly state this fact more clearly somewhere in 
> the draft.
> 
> Agreed, but the reordering amount can be as much as the window size -
> that's one point of the window. The compressor can be on the 
> uplink of a
> satellite channel.
> 
> Perhaps THIS is where the spec assumes low-BW channels, but 
> it's buried
> many pages late, and if this is the case, the doc should be entitled
> "TCP compression for low BW channels".
> 
> Overall, though, I don't like the assumption. We've 
> repeatedly seen such
> timely assumptions be inverted over a short period. It would be useful
> to appreciate why the reordering field can't be larger and adaptively
> compressed (LSB, e.g.) based on the feedback.
> 

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.

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.

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

> >>- - sec 9 the last paragraph seems to omit the possibility of secure
> >>header compression - why? that seems like an obvious 
> opportunity here
> >>that's being missed
> > 
> > No other ROHC profiles, nor the ROHC framework actually has 
> any support
> > for encrypting the compressed packets. The point is that if 
> you're using
> > HC, you need to save as many bytes as possible....
> > But on the other hand, there are people who want this:
> > draft-ertekin-rqts-hcoipsec-01.txt
> > 
> > Is that what you're asking about? That solution will be 
> easy to apply to 
> > ROHC-TCP as well as the other profiles.
> 
> I'm wondering if you're missing an opportunity to discuss the addition
> of a signature to the packets, akin to TCP/MD5 more than to 
> IPsec (which
> is what a quick glance suggests the above ID refers to - correct me if
> I'm wrong, though).

First of all, this is not something that we "rule out". There is nothing to prevent the development of a new profile that is more or less "let's 
use 0x0006 but we always add a signature field to packets, that is
placed in.....", which to me is the right solution, since that would
not burden this profile with extra overhead, while still allowing
this feature.

Secondly, this is not a part of the requirements RFC, so again, this
is not something we should fix in this doc.

Also, regarding the related discussion on the IANA reservations, I
must defer that to someone who was actually part of the 3095
development to answer (Carsten, L-E, can either of you answer this?)

> >>- - sec 4.2 discusses a state machine at the decompressor. 
> doesn't the
> >>compressor also have a state machine? It would need to know 
> >>the state of
> >>the decompressor, e.g.
> > 
> > 
> > Nope. The compressor has _state_, but it does not have a 
> state _machine_,
> 
> It has state and state transitions; that's a state machine to me ;-)

Ok, I expressed that a bit badly. What I meant was that
"it does not have a state machine with a discrete number of states
and since it has thousands of states, we cannot express that either
as a simple picture"

> 
> >>- - sec 5.3.4 what does REQUIRED mean in this context? it 
> >>seems like the
> >>decompressor can stop sending feedback whenever it chooses; 
> why bother
> >>REQUIRE-ing it?
> > 
> > 
> > Not really, if it has sent feedback once, it is supposed to 
> send negative
> > feedback for the lifetime of the flow. 
> > This is because reception of feedback disables the periodic 
> refreshes.
> 
> So the REQUIRED is there because if you fail to get the 
> feedback once it
> starts, you need to restart the compressor? (if so, it's fine)
> 

Yep, that's it.
 
> >>- - 6.4.2 is the header checksum on the main header, or header with
> >>options (as with IPv4)?
> > 
> > 
> > Now you lost me.... IPv4 headers with options are not 
> compressible with
> > ROHC-TCP (see default_methods for IPv4). This is common for all the
> > ROHC profiles.
> 
> Why do you care? If the IP options stay the same, why is it not
> compressible?

First, I'd again point at the requirements RFC as a motivation.

Secondly, this would create some overhead, since the IR & IR-CR
packets would have to explicitly carry the IPv4 header length
instead of just being able to know that it is 5 and adding bits for
a case that is expected to happen "almost never", does not seem like
an idea that I'd support :)

I hope that covered the remaining discussion items.

BR,
	Kristofer

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

---

From: Mark West <[email-masked]>
Date: Wed, 28 Sep 2005 10:44:24 +0100 (BST)

Kris, Joe,

A few comments on comments -- if this isn't getting too confusing ;-)

[I've snipped quite a lot of text out, to make it easier to find the
relevant bits]

Mark.

> Maybe also something to the abstract regarding the main target.

Sounds good to me.

This is only a problem where feedback is used, isn't it?  (You would have
ambiguity in the MSN used to (N)ACK...)  So we can support arbitrary
latency/speed links in uni-directional mode.

> > >>clear.
> > can be found there

I agree with Kris on this one.

As to whether the checking of the IP checksum is a 'MUST'...  well I'd
want to think about that a bit!

> not seem like The Right Thing(tm).

Well, we *do* have some requirement for misordering between compressor and
decompressor (it's not worded quite as I remember it, but my memory is not
what it once was!)

   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.

*If* (and it's a big if!) we wanted to add explicit support to ROHC TCP, I
would suggest adding an external sequence number -- i.e. provide the
misordering information that the requirements spec assumes will come from
the lower layers.

(Or as Kris suggests, a 'reordering tolerant' profile could be done
later).

Mind you, I don't necessarily agree that this will have a 'severe' impact
on compression efficiency: I guess it depends how you think about it.

Adaptive compression to handle re-ordering sounds like a fun bit of
post-graduate research, but a bit scary for ROHC TCP!

> is not something we should fix in this doc.

ROHC TCP can quite happily compress packets with the TCP/MD5 option.  I'm
not sure that adding security to *ROHC* is the right way to handle this,
when there's a perfectly good e2e method provided...
... just enable TCP/MD5 and have minimal overhead signatures with
compressed packets!

> an idea that I'd support :)

It's certainly a discussion that we've had.  But we concluded that it was
an 'almost never' case, so ruled out handling IP options.  That may be
right or wrong, but I'm pretty comfortable with the status quo...

---

From: Joe Touch <[email-masked]>
Date: Wed, 28 Sep 2005 15:51:24 -0700

> I've edited out the points where we seem to have agreement or

I think we're converging on most points quickly, which is good.

I've also edited out some stuff to be more compact in my reply ;-)
FWIW, this has involved re-wrapping in some places.

> discussed in a separate thread.

Same here.

(regarding checksum behavior)

> I'll discuss this further with the other authors, though.

MAY seems useful. Anything that parses an IP header, IMO, ought to be at
least a SHOULD if not a MUST, but as you point out it's harmless (except
in being inefficient). I talked it over with some other ISI-ers and they
noted that this could also impose a processing penalty on the
compressor, though I feel it's minimal compared to other work it does.

Either way is fine...

>>>> - - sec 8.1 if the MSN is only 4 bits, how will you ever detect
>>>> that the reordering is larger than 16 packets? ...
>>>
>>> The design is to only handle very few packets of reordering (the
>>> LSB offset of 3 means a packet can only arrive "three packets
>>> late"). Remember that this is reordering between the compressor
>>> and decompressor and not end-to-end reordering, which is always
>>> handled by the compressor....
>>
>> Agreed, but the reordering amount can be as much as the window size
>> - that's one point of the window. The compressor can be on the 
>> uplink of a satellite channel.
>>
>> Perhaps THIS is where the spec assumes low-BW channels, but it's
>> buried many pages late, and if this is the case, the doc should be
>> entitled "TCP compression for low BW channels".
>>
>> Overall, though, I don't like the assumption. We've repeatedly seen
>> such timely assumptions be inverted over a short period. It would
>> be useful to appreciate why the reordering field can't be larger
>> and adaptively compressed (LSB, e.g.) based on the feedback.
> 

That'd be great.

> case that we've been tasked to compress just to help a case that

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?

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

>>>> - - sec 9 the last paragraph seems to omit the possibility of
>>>> secure header compression - why? that seems like an obvious 
>>>> opportunity here that's being missed
>>>
>>> No other ROHC profiles, nor the ROHC framework actually has any
>>> support for encrypting the compressed packets. The point is that
>>> if you're using HC, you need to save as many bytes as
>>> possible.... But on the other hand, there are people who want
>>> this: draft-ertekin-rqts-hcoipsec-01.txt
>>>
>>> Is that what you're asking about? That solution will be easy to
>>> apply to ROHC-TCP as well as the other profiles.
>>
>> I'm wondering if you're missing an opportunity to discuss the
>> addition of a signature to the packets, akin to TCP/MD5 more than
>> to IPsec (which is what a quick glance suggests the above ID refers
>> to - correct me if I'm wrong, though).
> 
> First of all, this is not something that we "rule out". There is
> nothing to prevent the development of a new profile that is more or
> less "let's use 0x0006 but we always add a signature field to
> packets, that is placed in.....", which to me is the right solution,
> since that would not burden this profile with extra overhead, while
> still allowing this feature.

That might be noted in the security section.

> is not something we should fix in this doc.

It impacts the security section - even to state that this is compatible
with the security above would be a win. It seems more useful to do that
than to avoid it.

>>>> doesn't the compressor also have a state machine? It would need
>>>> to know the state of the decompressor, e.g.
>>>
>>> Nope. The compressor has _state_, but it does not have a state
>>> _machine_,
>>

That's true for TCP as well, however the 'signal' state machine in both
cases is only a handful of states whose transitions are fairly simple.

...
>>> compressible with ROHC-TCP (see default_methods for IPv4). This
>>> is common for all the ROHC profiles.
>>

I agree on the basis of statistics, but then this case should be noted
somewhere as well.

Joe