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

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Sat, 3 Sep 2005 10:11:17 +0200

Forwarded on behalf of Ted Faber!

Ted, thanks for the review!!

/L-E

-----Original Message-----
From: Ted Faber [mailto:[email-masked]]
Sent: den 3 september 2005 01:09
To: Lars-Erik Jonsson (LU/EAB)
Subject: Re: [rohc] WG last-call of TCP header compression

My biggest issues with the spec are not TCP issues.  There isn't
anything in here that I think will break the Internet or anything like
that, but I do think you'll want to tune up some things before you pass
it up to the ADs.  Big issues:

	1. Standards language.  There are lots of places - especially in
	   Section 5 - that don't read like a spec or provide detailed
	   guidance to implementors who aren't ROHC regulars.  Some of
	   these are just capitalizing the mays and shoulds that are
	   already there.  Many of them require a little bit of thought
	   about what you want to rule out or permit and why.  Putting
	   those in standards language reinforces the fact that these
	   are explicit decisions.  And once you've made those
	   decisions, it's worth a line of text to explain why to one of
	   the undergraduates who's implementing ROHC as a class
	   project. :-)

	2. Opacity.  It takes a while to get a handle on what's going on
	   here, and a few small changes can really help convince people
	   who are only casually interested that the spec is worth
	   reading.  Many of these are just a sentence or two adding
	   intuition.  One thing that I think would help *enormously* is
	   a table in Section 8 that shows typical compression ratios for
	   the various packet types under a set of realistic
	   assumptions.  It's very easy to finish this document as
	   written and have no idea how much this compression will help
	   you.  Again, a table that lists the compressed size of a TCP
	   header (no options), TCP w/PAWS & timestamps, TCP w/SACK for
	   1 or 2 IP-ID generation choices and some set of reasonable
	   assumptions would help motivate system designers to read and
	   consider this system.

My comments follow, relatively sequentially, and focused primarily on
sections 4-6.  I did not debug the formal notation because of my lack of
familiarity with it and my fervent hope that you ran it through some
kind of checker. :-)

Section 2:

While your definition of a short-lived TCP transfer is factually correct, it
really doesn't describe what's at issue for ROHC.  If I understand
correctly, you primarily care that there won't be enough time to
establish enough state to reasonably compress the headers and you're
depending on Context Replication to get any real benefit on these
connections.  The slow window change really isn't an issue for you as
far as I can see.

3. Background - This was a useful section for me to help understand what
else is being done here.

3.2 You mention that IPv4 stacks used over cellular should use
Sequential IP-ID allocation.  I'd do 2 things here.  First, adjust the
language so it's clear that you're not making a recommendation of that
(which would be pretty far outside your charter, right?).  Second, since
you mention this strategy, another sentence telling me why you think
it's true would help.  I'm not a cellular IPv4 provider, so I don't have
this intuition.  (You may want to just drop this sentence, since it's
not really directly relevant - ROHC TCP will work for cellular providers
whether they pick this encoding or not.  If ROHC works better with this
encoding, just come out and say that directly).

And a typo in the 5th paragraph of 3.2 "The TCP window bound the jumps in
acknowledgement..." should be "bounds."

In the paragraph: 

   With respect to TCP options, it is noted that most options (such as
   MSS, WSopt, SACK-permitted, etc.) may appear only on a SYN segment.
   Every implementation should (and we expect most will) ignore unknown
   options on SYN segments.

There's no "should" about it.  RFC 1122, Host Requirements, is explicit
that TCP stacks must always ignore unknown TCP options (p.85):

            A TCP MUST ignore without error any TCP option it does not
            implement, assuming that the option has a length field (all
            TCP options defined in the future will have length fields).
            TCP MUST be prepared to handle an illegal option length
            (e.g., zero) without crashing; a suggested procedure is to
            reset the connection and log the reason.

Section 3.3

This is a nice introduction to the idea of context replication and why
it's relevant to TCP compression.  What's missing is guidance to
implementors about when context replication becomes a good idea.  Is it
effective to do for only 2 connections?  Do 5-10 need to come?  What
parameters should I (as an ROHC compressor implementor) use to decide
whether to save a context for replication?  How long should I hold one
(at compressor or decompressor)?  I don't expect you to have integer
answers to those questions, but some guidance to implementors, or at
least an indication that those implementors need to think about the
issues would help.  If the CR document addresses these concerns, it
wouldn't hurt to put a sentence here that sends readers off to that doc.

Also in this section Joe Touch (who I know you'll be hearing from about
other things in this document) wrote an RFC on sharing information about
congestion information across multiple sequential TCP connections
between 2 hosts.  It's in RFC 2140, if you're curious.

All through Section 5 I have concerns about the absence of RFC 2119
standards language.  This seems like where you're describing the actions
that interoperating implementations have to agree on in order to work
together and there are a some places where things seem fairly loosely
specified.  Here are some of them that I think are particularly
noticeable, but I'd give this section another hard look:

5.2.3 Optimistic Approach

   When ROHC-TCP is used over lossy links, all information needs to be
   repeated by the compressor until it is fairly confident that the
   decompressor has received the information contained in the packet.
   Therefore, if field X in the uncompressed packet changes value, the
   compressor must send packets containing an encoding of field X until
   it has gained confidence that the decompressor has received at least
   one packet containing the new value for X. The compressor SHOULD
   choose a compressed format with the smallest header that can convey
   the changes needed to fulfill the optimistic approach condition used.

While I understand that you don't want to nail this down to "a
compressor must send field X 2 times" I do think you should bound the
behavior in some way.  You can imagine specifying a lose exponential
backoff kind of thing or, since we're talking about TCP, using the the
advance of the send sequence number by a certain number as an
indication that decompression is working.  Even if you're unwilling to
nail the duration of sending the new encoding down very tightly, I'd
suggest a couple reasonable metrics by which a compressor might gauge
confidence that the decompressor has synched state.  A recommended or
even suggested approach to try would go a long way.

In any case, I expect you want the "must" in "[...] the compressor must
send packets containing an encoding of field X [...]" to be a "MUST."
And because your SHOULD in the next sentence talks about selecting
packet formats, I'd do the same here: "The compressor MUST choose a
compressed format that encodes the change to field X until it has gained
confidence that the decompressor has received at least [...]"

Similarly in 5.2.4, that last sentence allows implementors considerable
latitude.  I'd suggest "... or any other strategy the implementor
chooses that is consistent with periodic context synchronization."

Section 5.2.5.1: Though it's probably beyond the scope of this document,
it would be awfully nice if you could piggyback the ROHC acks on
compressed TCP packets going the other way.  I understand that ROHC is
intentionally unidirectional and that in some cases, such piggybacked
ACKs wouldn't even pass through the same node as the compressor, but it
would be a nifty improvement.

Section 5.2.5.2: again description of operation without making clear
what the standards requirements are.  Here's your text:

   Negative acknowledgments (NACKs or STATIC-NACKs) are also called
   context requests and indicate that the decompressor context has been
   invalidated.  Upon reception of a negative acknowledgment, the
   compressor transits to a lower compression state.  On reception of a
   NACK packet, the compressor should re-send all dynamic information
   (via an IR or IR-DYN packet) next time it compresses a packet for the
   indicated flow.  On reception of a STATIC-NACK packet, the compressor
   should re-send all static and all dynamic information (via an IR
   packet) next time it compresses a packet for the indicated flow.

I suspect you mean:

   Negative acknowledgments (NACKs or STATIC-NACKs) are also called
   context requests and indicate that the decompressor context has been
   invalidated.  Upon reception of a negative acknowledgment, the
   compressor MUST transition to a lower compression state.  On reception of a
   NACK packet, the compressor SHOULD re-send all dynamic information
   (via an IR or IR-DYN packet) next time it compresses a packet for the
   indicated flow.  On reception of a STATIC-NACK packet, the compressor
   SHOULD re-send all static and all dynamic information (via an IR
   packet) next time it compresses a packet for the indicated flow.

I also think a sentence or two explaining why those SHOULDs are not
MUSTs would help implementors a lot.  For example, I can understand not
resending full compression state if the NACK is for a packet that a
previous NACK already generated a context refresh from this compressor
recently.  But there's no reason not to lay that out for someone.

Similar problem in 5.3.1.1:

The big problem here is that it's unclear what you mean by "Once a
packet has been decompressed correctly, the decompressor can transit to
the FC state, and only upon repeated failures will it transit back to a
lower state" - is that "can" a "MAY," a "MUST," or a "SHOULD"?
Similarly, below that in "If decompression may not be performed, the
packet MUST be discarded."  The MUST is great, but what's the lower case
"may" mean?  I assume that you mean that if the decompression is
impossible, the packet MUST be discarded.  I'd write that; "may" implies
asking permission from either an implementation or a standards body. :-)

Typo: "subject to the feedback rate limitation as describedin"  You need
a space between "described" and "in."

5.3.1.3:

   In the FC state, the decompressor moves to the SC state and discards
   all packets until a packet carrying a 7- or 8-bit CRC that
   successfully verifies is received if context damage is detected.

That sentence is really hard to understand.  I think it means that if
the decompressor is in the FC state and it detects context damage, it
moves to the SC state and discards packets until it can successfully
decompress one.  That needs to be rewritten.

Furthermore, it seems sort of strange to begin a section on the FC state
(the most efficient compression/decompression state) by telling the
reader how one leaves it.  Shouldn't you explain what the state does and
then how you leave it?  

Both this section and Section 5.3.1.2 need standards language.  E.g, "If
the decompressor is in the SC state and detects static context damage it
MUST transition to the NC state." and "If the decompressor is in the FC
state and detects context damage, it MUST transition to the SC state and
it MUST discard packets until it successfully verifies a packet using
the 7- or 8-bit CRC.  If the decompressor detects static context damage
before successfully validating a packet it MUST transition to the NC
state."

      In the Full Context state, decompression may be attempted
      regardless of the type of packet received.

That's ambiguous, too.  I think you're saying that in FC the
decompressor MUST decompress any packet presented to it, even if it does
not need to use static or dynamic context information to do so.  What
you've written seems to say that a decompressor is free to take a stab
at any packet it sees, but is under no obligation to do so.

Section 5.3.4

   When decompression fails, the feedback rate SHOULD be limited.  For
   example, feedback could be sent only when decompression of several
   consecutive packets have failed.  In addition, the decompressor
   should also limit the rate at which feedback is sent on successful
   decompression, if sent at all.  The decompressor may limit the
   feedback rate by sending feedback for one out of a number of packets
   providing the same type of feedback.

That's really not much to say about rate limiting.  Even if you're
unwilling to put a hard bound on the rate limiting behavior, at least
state the goals and maybe give a recommendation.  "Implementors should
design their rate limiting scheme to reduce the number bytes of ROHC ACKs sent
because each of these bytes is a byte of user data that cannot be sent,
and capacity must be scarce if one is using compression.  One must
balance this frugality with the need to communicate a loss of context
quickly to avoid sending many undecompressible packets forward.
Limiting ROHC acks to 10% of available capacity is good round number."  
Something like that - hopefully supported by some actual number you can
recommend. :-)

Section 6.3.1 : a nit. I'd change "The TCP options in the uncompressed
packet can be represented as an ordered list, whose order and presence
are most of the time constant between packets"  to "The TCP options in
the uncompressed packet can be represented as an ordered list, whose
order and presence are *usually* constant between packets."  The way
you've written it was hard for me to read because I wanted "most of the
time constant" to mean something like "the majority of the harmonic
frequency" rather than "doesn't change much".

Section 6.4.1

I'd provide a little more context for this.  For people who aren't
managing tunnels, the minimal encapsulation header doesn't come up much.
I had to look up RFC2004 to figure it out.

Section 6.4.5

I'd make it clear that the calculation "offset = (options length / 4) +
5" is in integer math.  I know it's pretty clear due to the fact that
it is going into a packet field, but it's worth saying that you only
take the integer part of that division.

Section 6.4.6

Typo: "On some TCP streams, such as data transfers, the payload size
will be constants over periods of time."  You mean "constant."

I'm also a little surprised that there is no option to make the scaling
factor explicit as there is in the acknowledgment scaling.  If the
compressor does know the factor, it seems more efficient to just send it
across.

Section 8.1

In describing the fields, I'd replicate the formal field description
here.  It's a little confusing when you're talking about the lsb sizes
of the MSN and sequence number.  I think if you used the lsb(x,y)
notation of the formal language doc, it would be unambiguous.

And also in Section 8.1, it would be very helpful to people not steeped
in ROHC lore, like myself, if in addition to those helpful intuitive
descriptions of the packet types you included representative sizes to
give a feel for how effective the compression is.  I know there are some
variables to consider, but just giving sizes for TCP packet with no
options, with timestamps and with SACK under a couple IP-ID allocation
strategies would *really* help the intuition for how effective the
system is.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 15 Sep 2005 10:33:05 +0200

Hi Ted, all,

First, I'd like to thank Ted for taking some of his time to make that review.

I try to provide some answers to Ted's comments inline, as a proposed resolution.

As a result, the draft has been updated, and a new proposed update of the draft is now available from the ROHC CVS:

http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/fn/draft-ietf-rohc-tcp.xml

It also includes the proposed resolution to Mark West's review of the packet format.

Thanks again for the review!

/Ghyslain

> that, but I do think you'll want to tune up some things 
> before you pass it up to the ADs.  Big issues:
> 

That's a very good comment.

The language should now be better in section 5.
I can't really go into details here, I suggest you have a quick look at the resulting section 5 in the updated draft.

I think that revisiting this section as per Ted's suggestion was really necessary!
 
> 	   assumptions would help motivate system designers to read and

Yes, this is a good suggestion.

While it did not yet make it in the updated draft,
I'll try to put up together a short text as a new subsection to section 4.
Something with a title like "Expected Compression Gains".

> connections.  The slow window change really isn't an issue for you as

The definition has been shortened, since some of the text was unnecessary from a header compression perspective. The description of the benefits is found in section 3.3 dedicated to this topic.
 
> 3. Background - This was a useful section for me to help 
> understand what else is being done here.

Good!
 
> (which would be pretty far outside your charter, right?).  

That sentence is now removed altogether.

> Second, since

We went with your later suggestion and removed the sentence.
 
> acknowledgement..." should be "bounds."

Done.
 
>             reset the connection and log the reason.

Actually, this is a good point. The paragraph is now removed because it is not necessary text from a header compression perspective.
 
> wouldn't hurt to put a sentence here that sends readers off 

No changes were made from this comment with respect to guidance.
This is because it seems from the comment that CR is misunderstood as being "context sharing".
It is not the aggregation of state for multiple flows that is at hand here, but rather pointing at existing data that one would like to reuse a copy for establishing new state in the decompressor. 

So instead, the second to last paragraph was modified to explicitly state that "a new context is initialized from a copy of an already existing context". This to avoid misunderstanding about CR not being about sharing state, but rather making a copy of existing state that seems proper to reuse (this is per replicated flow) and then updating it to reflect the needs of the new flow. Other than that, RFC4164 describes in quite lengthy details the entire mechanism.
 
> between 2 hosts.  It's in RFC 2140, if you're curious.

Thanks for the pointer. However, since context replication is about "reusing" and not "sharing", this is not directly applicable to CR.
 
> noticeable, but I'd give this section another hard look:

Done - hopefully you can have a quick look at the updated section and let us know if things got better and acceptable.
 
> confidence that the decompressor has received at least [...]"

The first "MUST" is fixed -- it now applies to the choice of the packet type containing an encoding for "X", but the SHOULD  is left because it applies to the choice of the "smallest packet format":

   Therefore, if field X in the uncompressed packet changes value, the
   compressor MUST use a packet type that contains an encoding of field
   X until it has gained confidence that the decompressor has received
   at least one packet containing the new value for X. The compressor
   SHOULD choose a compressed format with the smallest header that can
   convey the changes needed to fulfil the optimistic approach condition
   used.

> chooses that is consistent with periodic context synchronization."

Actually, the text is meant to leave this latitude to implementers.

When to stop doing this was added to the last part of the text instead, this is what really matters with respect to these kinds of context refreshes:
   
   Once the feedback channel is established, the decompressor
   MAY stop sending periodic refreshes.
 
> would be a nifty improvement.

This is already possible as part of the ROHC channel (the framework) as defined in rfc3095. All rohc profiles "inherit" the ROHC channel per definition. No change here.
 
>    packet) next time it compresses a packet for the indicated flow.

Actually, these are all SHOULD. An explanation regarding why was added and the description of the meaning of these NACKs for the compressor was improved as well as the assumptions it should then make regarding the decompressor state:

   On reception of a NACK feedback, the compressor SHOULD:

   o  assume that only the static part of the decompressor is valid, and
   o  re-send all dynamic information (via an IR or IR-DYN packet) next
      time it compresses a packet for the indicated flow

   unless it has confidence that information sent after the packet that
   is being acknowledged already provides a suitable response to the
   error recovery request.

   On reception of a STATIC-NACK feedback, the compressor SHOULD:

   o  assume that the decompressor has no valid context, and
   o  re-send all static and all dynamic information (via an IR packet)
      next time it compresses a packet for the indicated flow.

   unless it has confidence that information sent after the packet that
   is being acknowledged already provides a suitable response to the
   error recovery request.
 
> recently.  But there's no reason not to lay that out for someone.

The new text above should now cover this as well.

> asking permission from either an implementation or a 

Some changes were made to address this:
- the characteristics of the state have been clarified
  (or "entry" conditions)
- the verification/validation step was split from the
  state logic, and moved to a section common to all
  states: "Reconstruction and verification". This actually
  depends only on the packet type and not on the state
  the packet is received in.
- the "can" remained as it is, because it is not about
  "giving permission" but rather having the capacity; if the
  decompressor is in a specific state, it is not possible
  for it to decompress some of the packet types.
- the mention of the "feedback rate limitation" was moved
  to a common section. This is actually applicable to any
  type of feedback, independently of the state.
- a clearer "exit" condition was added:

   Once a packet has been validated and decompressed correctly, the
   decompressor MUST transit to the FC state.

> a space between "described" and "in."

Yes. 3 occurences have been fixed.
 
> decompress one.  That needs to be rewritten.

It's rewritten as follow:

   In the Full Context (FC) state, both the static and the dynamic part
   of the decompressor context is valid.  The decompressor moves back to
   the SC state if context damage is detected.

The condition stated by "until a packet [...] is received" was moved as the normative "exit" condition in the NC and SC states instead, where it seems more appropriate.

> reader how one leaves it.  Shouldn't you explain what the 

Agreed. Fixed in the new text.
 
> before successfully validating a packet it MUST transition to the NC

See the new text in the updated draft.

Note that there was an error for SC state - only packet with an 8-bit CRC can move the decompressor to a higher state... This is now fixed too.
 
> at any packet it sees, but is under no obligation to do so.

The "may" was changed to a "can", since this is not about mandating the decompressor to attempt decompression but rather meaning that it has the means to do its work on any packet type. It is not trivial to make normative text on a decompressor implementation about mandating the implementation to actually process the packet...  ; )
 
> Something like that - hopefully supported by some actual 

Hum. The conclusion seems that the best is still to change the "may" to "SHOULD".

It's not possible to put a limitation and to quantify the amount of feedback that should be generated, since the robustness properties of ROHC strive to bring the amount of feedback close to 0%. Feedback is meant to be generated only when things go bad according to the logic throughout the document (except for ACKs, which are explictly said to be optional), and thus depends on the amount of errors on the link. The actual suggestion that we want to bring forward here is as stated: "by sending feedback for one out of a number of packets providing the same type of feedback".

I would be very reluctant to attempt having some numbers on the feedback sending rate here.
 
> frequency" rather than "doesn't change much".

Done.
 
> I had to look up RFC2004 to figure it out.

The text describes a coding method for a specific field, nothing more.

It seems that it would be out-of-place to add more on the MINE header in this section.

The "glue" here between MINE (and other extension headers) and ROHC-TCP appear in section 4.3.3 "Compressing Extension Headers" which says: "ROHC-TCP compresses the same type of extension headers as in [rfc3095]". And then in 3095 there is some more context on those extension headers which I would be reluctant to take up again, since this part of 3095 is then already normative to ROHC-TCP.
 
> take the integer part of that division.

Done.
 
> will be constants over periods of time."  You mean "constant."

Done.
 
> compressor does know the factor, it seems more efficient to 

The reason why it is sent for ack scaling is because the scaling depends on the size of the packets flowing in the opposite direction. This is not necessary handled by the same compressor/decompressor pair. Otherwise, it could have been established without sending it explicitely. The reason why it is possible not to send it explicitely is that because an update to the context (for which the scaling factor belongs to) requires that the value be conveyed using a number of packets (optimistic approach), so the value can be directly observed instead from the packet size; then different packet type convey the scaled or the unscaled version for the cases where the scaling factor is not suitable. 

> strategies would *really* help the intuition for how effective the

Again, this is now on my TODO list.

Thanks again for your review!
It has contributed to make this draft significantly better already!

/Ghyslain

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 22 Sep 2005 15:21:46 +0200

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.

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

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

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.

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

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?

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

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

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

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

- - 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:
	- statistical analysis of packet flows
	- 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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- - 6.1.2 third paragraph, replace 'is likely to' with 'has a possible'
(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?

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

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

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

- - 6.4.2 is the header checksum on the main header, or header with
options (as with IPv4)?

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

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

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

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

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

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

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 22 Sep 2005 14:35:11 +0100

Hi Lars,

Thanks for forwarding this to the list.

> 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

Have I missed a step here? Where is the separate commentary on the
notation? I don't remember seeing that on the list!

Thanks in advance

Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 23 Sep 2005 10:13:34 +0100

Hi Joe,

Thanks for the feedback - I was just about to send a reply to the
original material which L-E forwarded, but I'll hold back now until I
can address your new comments also.

Regards

Raffles

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joe Touch
> Sent: Thursday, September 22, 2005 7:36 PM
> Cc: [email-masked]
> Subject: [rohc] Re: FW: [tcpm] WG last-call of TCP header compression
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Lars-Erik Jonsson (LU/EAB) wrote:
> > These comments were sent to me and Carsten long ago, I thought they 
> > were part of the mail I just forwarded. Joe, if these are not 
> > complete, please send the full set of notation comments to the rohc 
> > list.
> > 
> > Thanks!
> > /L-E
> 
> Sure - the high order 'bit' of feedback on the formal notation:
> 
> I find header layout diagrams useful, and wish that the 
> current notation would add to what they communicate.
> 
> In their current form, they don't - the biggest example of 
> this is the use of structured comments _outside the language 
> spec_ that indicate basically what header layouts would 
> (bitfield size and order in a single place). It would be nice 
> if the current notation could be 'compiled' into the layout 
> diagrams (at least), but that seems to be hard to do in its 
> current form.
> 
> As I hinted originally, it's not at all evident that this 
> 50-page document - a prerequisite to the TCP doc - makes any 
> of the TCP doc easier to understand or implement.
> 
> My personal impression is that this notation hurts more than 
> it helps, and should not be pursued further.
> 
> Joe
> 
> - ---------------------
> 
> 
> Some additional comments noted on a second pass; some of 
> these may be redundant with those previously noted:
> 
> - - the notation is BNF-like in some places (::=), C-like in 
> others, and decidedly bizarre (IMO) in others (===). If there 
> is a reason this doesn't look basically like a combination of 
> C-structures and C-code (maybe, *gasp*, C++ -like?), a case 
> needs to be made.
> 
> - - keywords are very hard to distinguish from variable 
> names; the use of structured keywords (co_format_a, 
> co_format_b, etc.) is extraordinarily cumbersome, esp. since 
> it can be easily replaced by a structure (co_format[a], 
> co_format[b], e.g.)
> 
> - - it doesn't seem that control fields can be conditional - 
> is there a reason?
> 
> - - the notation appears to imply that there is a 1:1 
> correlation between compressed and uncompressed messages; is 
> this necessary, and does it inhibit some forms of compression 
> (e.g., ACK compression could be performed by an intermediary)
> 
> - - the use of control fields, which hvae no uncompressed 
> value, should not need to be explained - it should be 
> highlighted in the structure. right now, the only way to find 
> such fields is exhaustive search of the structure.
> 
> - - some of the terms are obscure, e.g. why use 
> "uncompressed_value" as a function rather than the obvious 
> term "constant" or "fixed"? or "irregular" vs the term "raw" 
> or "uncompressed"? "log2" really means "bitsize", since it is 
> more like ceil(log2(N)).
> 
> - - the discussion of the IP checksum on page 12 failes to 
> indicate what fields the checksum is inferred from; that 
> seems more important than the opaque function 
> "inferred_ip_v4_header_checksum" - which isn't listed as 
> taking arguments.
> 
> - - 4.1 talks about the spec being written in 7-bit ASCII; 
> it's in 8-bit (in Internet RFCs), although it uses a subset 
> of values from 7-bit ASCII.
> 
> - - 4.2 should indicate whether 'alphabetic' is case 
> sensitive or not; later it specifies that constants must use 
> uppercase and others must use lowercase; this is archaic, IMO.
> 
> - - in 4.2.2 it makes no sense that bits on the wire are 
> always interpreted as unsigend, but the notation supports 
> negative values. They should be consistent. and if the value 
> is -1, then it should evaluate to -1.
> 
> - - in 4.5, why is the example of tcp_list_length illegal? 
> would it be illegal if it were:
> 	tcp_list_length:uncomp_value ::= (data_offset + 20) / 4;
> if so, why is the notation so pedantic here, and allows 
> inferences elsewhere about value/size?
> 
> - - 4.5.1 "-10" is "negative ten" commonly; the term 'minus' 
> usually refers to the infix binary operator, not the prefix 
> unary operator
> 
> - - 4.3.5 should discuss whether these logical operations are 
> short-circuit or not
> 
> - - 4.5.4 it seems odd to round to negative infinity, esp. 
> since the document goes to great lengths to explain that 
> values are unsigned. why not say 'round to zero'? and even if 
> signed values are used, why is round to negative infinity 
> useful or appropriate?
> 
> - - 4.5.5. what can be tested - only values, or formats too?
> 
> - - 4.6 the use of the "until EOL" comment character is OK, 
> but there should be an alternative which allows blocks of 
> code to be commented out as well (a paired comment delimeter)
> 
> - - 4.7.1 why is it not easier to say the following, esp. if 
> the length of the field is already constrained?
> 
> 	field:uncomp_value ::= 3;
> 
> I.e., why do you need both the uncomp_value selector and the 
> uncompressed_value function?
> 
> - - 4.7.2 why are quotes even needed? and why are only binary 
> strings allowed? i.e., why not use the notation consistently:
> 
> 	discriminator ::= 0b01101;
> 
> - - 4.7.4 static seems to apply (IMO) to all headers in the 
> flow, not just 'the same as for a previous header in the flow'.
> 
> - - 4.8 why is 'let' needed? why not just allow as above - 
> i.e., the use of the selector to indicate that only this 
> portion is set?
> 
> 	field:uncomp_value ::= 3;
> 
> also, this section says that lets must be used only inside a 
> field encodings list, but also discusses the use of boolean 
> expressions.
> 
> Huh?
> 
> why not use an 'if' or 'test', like other modern notations?
> 
> - - 4.9.5 as with the TCP doc, the IP ID cannot be valid if 
> it is zero; this should be omitted from the discussion
> 
> - - A.3 "using this simple scheme" - the fixed values are per 
> flow, or per protocol? if the latter, they MUST be dependent 
> on the version number of the protocol
> 
> - - A.5 the example should use version numbers; otherwise, 
> what heppens when a new version appears?
> 
> - - pg 44 discussion on using 0 vs 01 - 'care' shouldn't be 
> needed; the notation should suggest this.
> 
> 
> > 
> > 
> > -------
> > draft-ietf-rohc-formal-notation-09.txt
> > 
> > Overall comments:
> > 
> > 	the notation description is easy to read, but has areas that
> > 	don't make sense:
> > 		- if every header has two (uncompressed, compressed)
> > 		or three (+ control) parts, why not define the structure
> > 		that way? right now it looks too much like free-form
> > 		C structures on which you impose rules, but it is hard
> > 		to _see_ whether the rules are followed
> > 
> > 		- if there are alternate formats, why not list them
> > 		as alternates (using BNF "|") rather than new names?
> > 		i.e., why use co_format as a prefix, rather than
> > 		say:
> > 
> > 			header === {
> > 				<base format>
> > 				COMPRESSED
> > 				cf1 = ...
> > 				cf2 = ...
> > 			}
> > 
> > 		i.e., omit the word uc_format, and the prefix co_format,
> > 		and use a single keyword to separate the parts;
> > 		allow the co_format headers to be named without
> > 		requiring prefixes
> > 	overall, it would be useful if the notation ended up being
> > 	somewhat self-descriptive; this seems very contorted to me
> > 
> > 	the examples tend to show the exceptions rather than the rules;
> > 	get the base rules out, then show exceptions
> > 
> > 	there should, IMO, be exactly one way to describe things
> > 	in the basic language; having equivalent expressions is a
> > 	good way to end up with incomparable alternates
> > 
> > MAJOR QUESTIONS:
> > 
> > *notation appears to ignore reordering?
> > 
> > 	mentions loss and corruption, but not reordering
> > 
> > *is there any notion of keeping multiple states
> > 	i.e., keeping K parallel interleaved streams -
> > 	which can tolerate reordering up to K-1 packets,
> > 	but which are all associated with a single stream?
> > 
> > *4.9.4.2
> > 	if the compressor can pick any format that succeeds,
> > 	does this mean it cannot pick the 'better' format, for
> > 	some definition of 'better'? (shorter, uses more recent
> > 	context, etc.)
> > 
> > MINOR OBSERVATIONS and QUESTIONS:
> > 
> > 4.9.2.1
> > 	discusses LSB-ish fields of seq nums, but suggests the
> > 	field be split into two, rather than LSB-encoded
> > 	this is a poor example, IMO
> > 
> > 4.7.4
> > 	*static is defined as 'same as previous packet's value',
> > 	but should be 'constant within a flow'
> > 	the two do not seem the same - are IDs static if prev
> > 	packet's 'more fragments' bit==1?
> > 
> > 
> > notation comment
> > 	::= is EBNF - it might be useful to use something that
> > 	indicates that the encoding is bidirectional, and which
> > 	is the larger, e.g., <=-> or <<--> or somesuch
> > 
> > 	the way in which control_field_3 is different should be
> > 	more readily apparent from the syntax (sec 3.2)
> > 
> > 	constants are defined and structures defined using the
> > 	same operator (=)
> > 
> > 	log2(w) seems misnamed; bitsize(w) is more descriptive
> > 
> > 	are boolean operators short-circuit? (doesn't matter
> > 	if there are no side-effects)
> > 
> > 	why do compressed values have shortcuts of 'xx', where
> > 	there is no shortcut for uncompressed values?
> > 
> > 	irregular seems an odd term; why not just indicate the
> > 	length and let the encoding be left absent?
> > 
> > 	it would be useful to define CRC as taking a list of
> > 	polynomials as an argument, or provide an equivalence macro
> > 	(sec 4.7.6)
> > 
> > 	why have LETs and encoding methods? why not define one, and
> > 	let there be an optional macro that equates the two? (4.8)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDMvmoE5f5cImnZrsRAt6bAKDLLObg1rpDsdQ7Ck8wB56CZp4ksgCgy/SC
> 1uFK01TMUEDzHDlWEBLgqo4=
> =qxGW
> -----END PGP SIGNATURE-----
>

---

From: "Trabelsi, Chokri (Chokri)" <[email-masked]>
Date: Thu, 29 Sep 2005 10:45:57 -0400

>>we have a document headed for publication on the topic of rohc over reordering channels

Do you know when this "rohc over reordering channels" will be published.
Is there a new contribution on this besides the following (draft-kapoor-rohc-rtp-new-requirements-00, draft-ietf-rohc-rfc3095bis-improvements-01, ROHC-draft-ietf-rohc-over-reordering-03)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Lars-Erik Jonsson (LU/EAB)
Sent: Thu, September 29, 2005 3:29 AM
To: Joe Touch; Kristofer Sandlund (LU/EAB)
Cc: [email-masked]
Subject: RE: [rohc] Re: [tcpm] WG last-call of TCP header compression

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

---

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

http://www.ietf.org/internet-drafts/draft-ietf-rohc-over-reordering-03.txt

See the RFC editor queue:
http://www.rfc-editor.org/queue.html

/L-E

> From: Trabelsi, Chokri (Chokri) [mailto:[email-masked]]
> Sent: den 29 september 2005 16:46
> To: Lars-Erik Jonsson (LU/EAB); Joe Touch; Kristofer Sandlund (LU/EAB)
> Cc: [email-masked]
> Is there a new contribution on this besides the following 
> (draft-kapoor-rohc-rtp-new-requirements-00, 
> draft-ietf-rohc-rfc3095bis-improvements-01, 
> ROHC-draft-ietf-rohc-over-reordering-03)
>