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

From: "Kristofer Sandlund (LU/EAB)" <[email-masked]>
Date: Tue, 27 Sep 2005 10:57:39 +0200

Hi Joe,

I've finally gotten around to comment on your ROHC-TCP review.
Comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 22 september 2005 15:22
> To: [email-masked]
> Cc: Joe Touch
> Subject: FW: [rohc] Re: [tcpm] WG last-call of TCP header compression
> 
> 
> Forwarded on behalf of Joe Touch!
> 
> Joe, thanks for the review!!
> /L-E
> 
> 
> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> 
> Hi, all,
> 
> Sorry for the undue delay; part of it was travel, part was my own
> overload, but no small part was the obfuscation created by 
> the notation
> - - which I've already commented on separately.
> 
> Joe
> 
> - -------
> 
> Feedback on draft-ietf-rohc-tcp-10.txt
> 
> - --------------------------------------------
> Overall:
> 
> I felt that, as I suspected from my initial comments on the notation
> document, this is a fine example of the inadequacies of the notation,
> more than a useful description of how to do TCP header 
> compression in a
> way that addresses either the unique characteristics of TCP 
> w.r.t. ROHC
> or would be sufficient to code interoperating implementations against.
> 
> - --------------------------------------------
> Global issues / errors (IMO):
> 
> - - the term 'link-level' is used throughout; while I appreciate that
> compression is over somethink akin to a 'virtual link', this 
> is not very
> clear from this document. If it is part of the core ROHC 
> concept, enough
> of the idea needs to be expressed here to provide a common 
> language from
> which to discuss the details.
> 
> I.e., in most places link means "over the compression path", but in
> various places it is used more like link layer, link endpoint, etc.
> 

I think what "link" and "channel" means is something that is quite well 
defined within the ROHC specifications (RFC3095 & RFC3759).
Maybe we should add a reference to 3759. Would that solve your concern?

If not, could you point to where you feel that we use a conflicting
meaning of the term(s). I'm so used to reading these terms in a HC
context, so I can't really tell which you consider troublesome.

> - - sec 3.2 IP IDs are not valid if zeroed. If this has 
> changed after RFCs
> 791 and 1122, then please cite the change to those specs, but 
> a zero IP

We've been told on many occasions that the zero-IPID allocation is used
in some Linux stacks, and also some providers of cellular equipment have
stated that they will use such an assignment policy for non-fragments. 
Therefore, the spec tries to accomodate for behavior that we know that
implementations will see "out in the wild".
See for example draft-kapoor-rohc-rtp-new-requirements-00.txt which is
a clear request for ROHC to support this.
ROHC does not force any kind of behavior on the endpoint stacks, so
if we accomodate for people who use this not-so-very-legal approach,
it does not mean that they have to use it.
We've already produced profiles that do handle this (IP-only and UDP-lite)

> ID would have some consequences:
> 	- fragments of different packets could be reassembled
> 	  in different ways if reordered (ID=0 is a valid ID),
> 	  as per RFC791

Each ROHC-TCP compressible header chain must end in a TCP header, and
therefore fragments are not an issue for this spec (it is illegal to
compress these).

> 
> 	- different packets with matching src/dst addrs might be
> 	  dropped (duplicate detection, as per RFC1122)

I guess this is an issue for the people who design their IP stacks this
way, and not really a problem that ROHC should address.

> 
> this also apperas in 6.1.2
> 
> - - sec 6.1 restate the second sentence of the first 
> paragraph. Since TCP
> connections last longer than 2xMSL and windows wrap, seq/ack 
> num fields
> are NOT unique throughout a flow, but only within 2xRTT for that flow.

Do you mean in 6.1.1? Which says:

   Unfortunately, there is no guarantee that sequence number and
   acknowledgment number fields will take on unique values for each
   packet in a TCP/IP flow.

I can't see that we state that the they are unique, it says 
"no guarantee" or am I missing something?

> 
> - - sec 6.1.1 paragraph starting "The MSN field", regarding sentence
> starting "The decompressor always", is feedback compressed? this seems
> like it's worth discussion, even if the answer is 'no'.

Feedback usually compresses the MSN if that's what you're asking.
You _can_ send all 16 bits, but that's not likely to be needed.
This is no different from 3095, so it's kind of ROHC framework operation.

> 
> 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.
Feedback is also just an optional enhancement, so if someone would
dare to run HC on a high-speed link, there's always the option to
run unidirectionally and therefore avoid MSN wrap issues (with a slight
loss of compression efficiency due to the periodic refreshes of course).

> 
> - - 6.3.4 regarding NOP options - this assumes that NOPs 
> don't need to be
> preserved w.r.t. position. I agree, but can't find a reason 
> that must be
> true - in fact, since they're there to preserve alignment on word
> boundaries, and the definition of a useful 'wordsize' depends on the
> implementation (i.e., it's up to the implementer to decide whether to
> align on 16, 24, 32, etc. bit boundaries if they want). this 
> means that
> they can't just be omitted from the compressed list

The NOP is not omitted from the packet, it is just omitted from the
"item_1...." field. Its type indicator is still present in the "XI_1.."
field. Therefore, the order is always maintained.
If you think the text is unclear, could you please point out more exactly
which piece of text that confuses you?

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

> 
> - - sec 8, last paragraph
> THIS IS A MAJOR ISSUE - this is a really good example of why the
> notation is incomplete. Both the notation description doc as well as
> this first spec using it end up with the same formalization for
> comments. that seems like a fairly explicit indication that there is a
> failure in the language. in particular, I disagree with the last
> sentence - this SHOULD BE NORMATIVE!!!

The field length information is in the encodings, and therefore these
comments are actually redundancy to help readability. We can remove all
these "field width comments" and the FN would not lose anything.
But I defer this to the separate discussion on the FN in progress.

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

> 
> - - sec 8.1 why are there 10 different compressed formats? more
> specifically, why these groups and not others? I can think of 
> a few reasons:

Hmm.... the short descriptions in 8.1 are supposed to convey why each
format is chosen (we dropped format 7 since the draft as per Mark's
mail to the list a couple of weeks ago).

> 	- statistical analysis of packet flows

I would say that is the main motivation for these formats.
See the field-behavior draft (in the references).
Also, the fact that we choose these to be the "best compression ratios"
does NOT stop people from compressing the more "unusual cases", it's
just that they will get a couple of bytes extra to transmit. We need to
optimize the formats for the traffic the analysis we have.
(for example, format 5 is suitable for connections where data flows
in both directions, so we're not ruling out those connections)

> 	- ease of compressability
> It'd be very useful to explain why these 10. in particular, I really
> expected a few things UP FRONT:
> 
> 	- state of the compressor
> 	- state of the decompressor
> 	- sets of compressed packet types
> 	- sets of signals from compressor to decompressor
> 	- sets of signals from decompressor to compressor
> and, as importantly,
> 	- a state transition table that describes how these all
> 	  relate to each other

The normative parts of this are in chapter 5, and I see no good reason
for trying to force more behavior than that on the compressor, since
we're really just specifying the decomrpessor. The compressor 
should be given a lot of freedom on how to compress.

An implementer will see from the FN and/or box notation which fields
that can be compressed by each format and from there infer which
"state" the compressor should be in.

> 
> Short of this, it seems impossible to actually build an interoperating
> implementation - not to mention the number of "please see some other
> doc" statements, describing checksums, etc. This doc really should be
> self-contained, or at least much more self-contained than it 
> currently is.

I very much disagree on that. It should be easy to build an
_interoperating_ implementation (since you can just send IR packets all
the time and be perfectly interoperable), but it is not meant that two
implementations of ROHC-TCP should be _identical_. All you need to do to 
interoperate is to follow the MUSTs in chapter 5 and make sure that the
packets you send are compressed according to the FN.

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

> 
> - - sec 10 describes reserving a profile (0x0006) for TCP [which seems
> fine] and a class of profiles (0xNN06) for future versions.
> 
> This _SCREAMS_ for a version number separate from the 
> profile, IMO. I'm
> surprised at yet another protocol without a version ID; this should be
> REQUIRED of all new protocols (I'd be more in favor, e.g., of 
> a "Version
> Considerations" section being required, than some of the other recent
> additions).
> 
> IMO, it's inappropriate; there's no precedent in the other 
> ROHC profiles
> reserved in RFC3095 (sec 5.1.2), except for pending ones 
> (e.g., UDP-lite
> - - which **ought** to be a variant of UDP!!!).
> 
> If there are two separate fields here - profile (last byte) 
> and version
> (first byte), RFC3095 should have spec'd that.

I just re-read the IANA section of 3095, and I agree that the text there
is fishy to say the least. The intention of that text (as far as 
I've been told) is that future profiles should treat the field as 
ROHC-TCP does (i.e. the 8 MSBs should be profile version and the LSB profile number).
This is not really a ROHC-TCP specific issue, this scheme has already
been used (i.e. RFC3409 is supposed to be a new version that is a superset
of RFC3242). This is not something that can be changed here....

> 
> - --------------------------------------------
> Local issues / clarification:
> 
> - - sec 3.2 discusses fields that require more sophisticated 
> mechanisms
> because they change; DF, MF should be part of this (IPv4 still allows
> fragmentation)

Again, fragments are not compressible. See the "default_methods" of
ipv4 (page 59 in tcp-10). You must use the IP profile to compress
fragments.
But ok, DF could possibly be mentioned in 3.2.

> 
> - - sec 3.2 observes that TCP connections are mostly one-way; similar
> assumptions in the past have left later users with complex mechanisms
> (assuming 2-way means needing ACK piggybacking) or poor performance
> (using time-since-receive rather than time-since-sent to adjust TCP's
> window after an idle period, because 'TCP is mostly symmetric'). IMO,
> it's useful to describe where symmetric and asymmetric cases 
> differ, but
> NOT to assume prevalence of either except for a particular deployment.

We do not rule out compression of these cases, we only optimize the
compression for the cases described in more detail.
Maybe section 3 should be more general instead of describing the most
usual cases, but I don't see this as a problem for the spec, it's
just a background chapter after all.

> 
> - - sec 3.3 while it is true that most flows are short, most 
> packets are
> from large flows, i.e., the former does not imply that cross-flow
> optimization will be cost-effective, and the latter implies 
> it will not.

I actually feel that this section should go away altogether. ROHC-CR was
developed to taget should-lived flows, but it is a general mechanism
that does not care about the lifetime or content of the flow, so
I would prefer to just talk about "fast context initialization".
I think it is a lot better to talk about "what does CR do", instead of
"what was the motivation for CR". All it really does is that you can
replace an IR (uncompressed packet) with a IR-CR (semi-compressed).

Other authors disagree with this approach, though.

> 
> - - sec 3.3 persistent HTTP connections are the norm, although many
> browsers also allow up to some fixed number of parallel connections
> between two sites to avoid head-of-line blocking. Persistent 
> connections
> were an option as early as HTTP 1.0, and while were supported 
> explicitly
> in 1.1, 1.1 is not required). A good ref for Persistent-HTTP is:
> V. N. Padmanabhan and J. C. Mogul, "Improving HTTP latency," in
> Proceedings of the Second International World Wide Web 
> Conference, Oct.
> 1994.

See above, I don't think 3.3 should be in the spec. At all.

> 
> - - 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_,
and "upwards state transition" is never mandatory. If the compressor
had a state machine, it would probably have 3000 different states.
I think the re-write we did to chapter 5 after Ted's review (with a lot
more standards language) should make this more obvious.
(See http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/fn/draft-ietf-rohc-tcp.xml)

> 
> - - sec 5.1 it's not clear what 'restarting the compressor' means (end
> first paragraph) if only one mode transition is allowed (second
> paragraph). what is the meaning of a restart? If this is 
> focusing on the
> fact that all prior state is purged (which is the only case I can see
> being consistent with what is written), it would be useful to 
> say a bit
> about that, i.e., why 'restarting the compressor' is different from a
> transition from bidirectional back to unidirectional.

With the re-write mentioned above, this section is no longer normative,
it has been moved. The content of this is covered by other sections now.

> 
> - - sec 5.2.4 what is the purpose of timeouts? is there some 
> period over
> which state is defined as being stale? or is this a feedback failure?
> more needs to be said.

Refreshes are only used when operating unidirectionally (when no feedback
is used), so this is to make sure the context is up to date when the
decompressor cannot (or will not) use feedback to signal context
corruption.

> 
> - - sec 5.2.5 the compressor would need to send periodic 
> refreshes on long
> delay paths - the issue is how long it takes to reestablish state (or,
> restart the compressor). it might be useful to proactively restart the
> compressor periodically (i.e., this is how I think of MPEG 
> working in a
> sense).

I'd say that's an implementation issue for a specific deployment,
and if you're running on a long-delay link, you probably won't use
feedback at all. I don't see a reason to add text for this.

> 
> - - sec 5.2.5.1 ACKs represent the _past_ state of the 
> compressor (i.e.,
> 1/2 an RTT ago), and do not account for packets still in 
> transit to the
> compressor (in the reverse-path pipeline). this section does 
> not seem to
> take this into account.

This is handled by the MSN (it indicates which state of the context
that was ACKed). Again, the new text should be a bit more clear.

> 
> - - sec 5.2.5.2 it would be useful here to spend more space 
> discussing the
> difference between NACK and STATIC NACK and why each is sent.
> 

See new text.

> - - sec 5.2 there are a number of transitions that seem to be 
> missing from
> the state diagram:

This only illustrates decompressor state's relation to decompression
success. If we were to include packet input & output plus feedback
output, I think this would become too cluttered.
If we need to have all that in the diagram, I'd much rather remove the
diagram altogether and let the MUSTs and MAYs describe this alone.

> 
> 	- transitions that stay in the same state but emit a packet
> 	e.g., in NC, receipt of an IR with CRC failure or a non-IR
> 	results in a STATIC ACK,
> 	and in SC a failure generates a NACK
> 
> 	- none of the arcs show the packets received or sent
> 	e.g., NC to FC on "Success" is really on receipt of a valid IR
> 
> 	- context damage and static context damage are shown as separate
> 	steps. is there a possibility that both happen in one step? if
> 	so, that arc ('full damage') is missing
> 	
> Also, if the decompressor has a state diagram, so should the 
> compressor!

See earlier comment. Also, we had this in 3095, and that caused a more 
problems that it solved.

> 
> - - sec 5.3.3 when CRC validation fails, what portion of the packet is
> still meaningful and why? i.e., if the CRC os over the packet 
> type, then
> a CRC failure means you can't act on the packet type value. this is
> either a problem or needs to be clarified (and the fact that I can't
> readily tell is more evidence of how obfuscated this spec is)

If the CRC fails, the packet must always be discarded.
The new chapter 5 should be more clear with the addition of more
standards language.

> 
> - - sec 5.3.4 how does a compressor know to whom to send 
> ACKs, etc? What
> happens if there are multiple compressors and different 
> return paths, i.e.:
> 
> 	a------>b=======>c------->d______>e------>f
> 	         <************************
> 
> If b===c is one forward compression path, and d___e is another, what
> happens if the return path from e towards a ends up going around d?
> won't every ACK end up resetting the compressor at b?
> 

These are ROHC framework issues. See RFC3095 and possibly RFC3759. 

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

> 
> - - sec 6 why is the profile ID for TCP spec'd as two bytes (0x0006)?
> where are profile ID's defined (I didn't catch it if it came 
> before this)

See earlier.

> 
> - - 6.1.2 third paragraph, replace 'is likely to' with 'has a 
> possible'

sure.

> (likeliness is for the compressor to determine, IMO), and 
> omit the part
> about zero ID (as per the global issue); as to what can be 
> assigned, why
> does it matter what the compressor assigns to the tunneling header?

Due to the packet formats, only the innermost IP-ID can be compressed
with a sequential pattern. See the packet formats.

> 
> - - 6.3.1 some of the steps assume that it is more likely to change an
> option content than to add/delete options - again, why not let the
> compressor determine that?

It _is_ the compressor that decides this.
Could you point out which text is the offending to you?

> 
> - - 6.3.4 EOL option padding should mention the use of NOP for that
> purpose (another reason NOPs can't be omitted from the list, 
> as per the
> global issue)

Why should it mention this? The compressor should just compress what
it receives and the current scheme has no problems with either of these.

> 
> - - 6.4.1 end of last paragraph, this implies that the checksum is NOT
> being used; is it being checked at the compressor? if not, why not (it
> seems like it's wasting BW - see the general issue) and if 
> this ends up
> being covered at this hop by a different checksum then it would be
> useful to say that explcitly
> 
> the same comment applies to the end of 6.4.2

See earlier. Also,I guess we could mention that the ROHC-CRC covers this.

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

> 
> - - sec 8.2 page 39 presumably 'insert reference here' will 
> be filled in
> sometime?

Ahh.. we missed that. Will fix.

> 
> - - sec 8.2 page 53, definition of crc3 seems odd
> why bother adding the 'uc_format' if the right-hand side is a null
> string "= ;" again, this seems confusing
> 
> same for crc7

This I'll have to ask the FN guys. I can't remember this :)

> 
> - - sec 8.2 page 75 while I appreciate the economy of setting 
> the default
> methods to 'static', that seems dangerous; I would expect the 
> default to
> be what is NOT compressed - i.e., why aren't these described 
> throughout
> as irregular?
>
> it seems confusing to list these as 'static' and then to have
> co_format_tcp_static to be named 'static' as well and end up declaring
> the port fields as irregular
>

Well, no. When these are not present in the compressed packet (in all
cases but IR and IR-CR), then they are static, so that's the "normal case"
and therefore should be the default.

> I would expect the opposite, i.e. - default would be irregular, and a
> format called 'static' to override defaults and call the 'static'
> 
> - - sec 9 the first paragraph describes TCP encryption; I'm 
> familiar only
> with TCP authentication. it'd be useful to provide a reference and
> describe what you mean more specifically

Sounds reasonable to me.

> 
> - --------------------------------------------
> TYPOS/MINOR EDITS:

These seem reasonable.

> 
> - - sec 5.2.5.1 last sentence of the first paragraph change 
> "transmit" to
> "transmitted"
> 
> - - sec 5.3.4 at end of paragraph starting "When 
> decompression fails,",
> append "or per unit time. Integrate the first sentence of the 
> following
> paragraph (The decompressor MAY) just before "In addition". Omit the
> last sentence of the last paragraph - you already said that the
> decompressor may send an ACK upon sucessful decompression of "any"
> packet type - what's the point of listing types - "any" means 
> "any" ;-)
> 
> - - sec 6.1 second paragraph, sentence beginning "These 
> control fields"
> seems redundant with the previous paragraph, and can be omitted.
> 
> - - sec 6.1.1 first sentence, replace "sequence" with "TCP 
> sequence" and
> replace "acknowledgement" with "TCP acknowledgement" (unless you're
> referring to compression sequence or acks, i.e.)
> 
> - - sec 6.1.1 paragraph starting "When the MSN", replace 
> monotonously with
> monotonically.
> 
> - - sec 8.1 last sentence doesn't make sense - "to control 
> which fields
> that are present" is confusing; please reword.
> 
> 

Thanks for a very thorough review!

We've been trying to get people to review this many times over the last
two years with no real luck, so it's great to get some fresh eyes
that can point out the flaws we have with the text. I guess we've
gone a bit blind from having worked with this for far too long.

Me and Ghyslain will put together a new update (-11) next week based on
the thing in the CVS as well as these comments.
If anyone else has comments, now is definitely the time to raise them!

BR,
	Kristofer Sandlund

> _______________________________________________
> 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: Tue, 27 Sep 2005 09:00:29 -0700

AOK - I'll see if I can add to the discussion. I really don't want to
beat a horse once my position is made, though...

> Maybe we should add a reference to 3759. Would that solve your concern?

It might, although I'd favor quoting the relevant definition early in
this document to make it more clear as well (presumably a single
paragraph). I would also prefer using a single term throughout the doc,
whatever it is.

> context, so I can't really tell which you consider troublesome.

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

> implementations will see "out in the wild".

It's important to distinguish between "out in the wild" variants and
standards-violating bugs. This is the latter - regardless of whether
it's seen out in the wild. It need not be supported, and should not be
used as an example of anything other than a bug.

> a clear request for ROHC to support this.

Until the standards are changed, it would be inappropriate to honor that
request.

> We've already produced profiles that do handle this (IP-only and UDP-lite)

I appreciate that this error has propagated into othre docs; if they've
made it into RFCs, then the IESG or cross-area review failed, IMO.

> therefore fragments are not an issue for this spec (it is illegal to

Understood, but it'd be better to avoid using a spec violation as an
example.

> way, and not really a problem that ROHC should address.

Agreed as well, but again it's better to avoid the use of spec
violations as examples.

> "no guarantee" or am I missing something?

Yes- it was 6.1.1

"no guarantee" implies a bit of an expectation that it should happen,
though there's no enforcement. I'm stating it WILL NOT HAPPEN. That's
different from "no guarantee" - i.e., it IS a guarantee that it probably
WILL happen within a flow (unless the flow is smaller than a window,
i.e., a 'mouse').

> This is no different from 3095, so it's kind of ROHC framework operation.

Understood, but again it is worth a paragraph or two to explain, even if
it's to include a ref to 3095 on this point.

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

> loss of compression efficiency due to the periodic refreshes of course).

It can't just be an option; it will break if the user picks the wrong
thing. I.e., break in ways that would be hard to debug. Again, if this
breaks, it needs to be detected or prohibited in the mechanism.

> which piece of text that confuses you?

The "never appear in an item list" might be appended with "although its
position and length is preservd in the ??? [parent?] field, so it can be
reconstituted correctly, as it would need to be to preserve option byte
location."??

> over the uncompressed packet, these checksums cover only a subset of the

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

> But I defer this to the separate discussion on the FN in progress.

As with above - "the answer is buried many pages away, perhaps on
separate pages in separate places and if you were a computer you would
have known that" is a poor reason. Anything useful enough to be
normative in the examples is useful enough to be in the FN - even if it
is redundent (maybe especially so!).

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

> mail to the list a couple of weeks ago).

There's no real reason given as to why 10, not 8. Each format makes
sense in of itself, it would be to list 'design rules' or 'overall
perspective' that show how anyone else would come to the same conclusions.

> in both directions, so we're not ruling out those connections)

Understood - again, that's worth noting, as is the assumption of
statistics - as well as a _citation_ of the field-behavior draft there ;-)

> should be given a lot of freedom on how to compress.

Agreed - but if I don't have the above, I don't see how a decompressor
can operate correctly. Right now there's too much freedom in that regard.

> "state" the compressor should be in.

Why infer? Why not indicate it in the notation (even if it's not in the
packet)?

> packets you send are compressed according to the FN.

We disagree on this point; if that's the acid test, then someone ought
to at least try a 'clean room' implementation - using this doc alone
(with it's references) to build one. That'd at least show whether it
succeeded - and would, IMO, be part of the "running code" requirement...

(or is that what would make this go from PS to DS? and do we want to
wait until then to find out?)

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

> of RFC3242). This is not something that can be changed here....

Why not? Just because previous profiles made the error is no reason to
propagate it ;-) This is an opportunity to fix that issue - it's a
fairly simple fix, and would free up a lot of space in the profile space
that would have been used for TCP versions, even if it won't address
UDP/etc.

> But ok, DF could possibly be mentioned in 3.2.

Sure, perhaps reiterating that MFs' can't be compressed here.

> just a background chapter after all.

Not a big problem, agreed, but it's always useful to be clear about the
assumptions and explain where they might change or would affect your
solution (either by breaking it or even defeating compression).

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

> decompressor cannot (or will not) use feedback to signal context

OK - it'd be useful to include that.

> feedback at all. I don't see a reason to add text for this.

It goes to "explain your assumptions, explain where they break" as I
noted above. Again, unless the doc has some very heavy flavoring
(including a title and abstract change) to focus on slow links, you
can't know where it'll be deployed. Long fat pipes may really need this
compression anyway - consider interplanetary!

> These are ROHC framework issues. See RFC3095 and possibly RFC3759. 

AOK.

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

> Could you point out which text is the offending to you?

I re-read it, and it looks OK as-is. I misinterpreted the list numbers
to indicate priority.

> it receives and the current scheme has no problems with either of these.

This comes from my confusion about the NOPs above; given the
clarification, it's OK.

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

Why do you care? If the IP options stay the same, why is it not
compressible?

> and therefore should be the default.

So if a static method is the normal case, then the 'really' default case
is that the compressor fails and turns off? I.e., that the packets are
sent unmodified? That makes sense, but it's counterintuitive to read, if
it's true.

> These seem reasonable.
...
> If anyone else has comments, now is definitely the time to raise them!

Again, please take my input with the following grains of salt:

	a) I do NOT have enough background about ROHC; that could be
	a good think for this sort of feedback, but I will probably
	ask naiive questions

	b) I DO have a fairly deep background about IP and TCP,
	so I would hope that 'people like me' could use this sort
	of doc

Thanks again for being patient with my input,

Joe