RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
draft-ietf-rohc-tcp-16
Yes
(Magnus Westerlund)
No Objection
(Bill Fenner)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lars Eggert)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
Note: This ballot was opened for revision 16 and is now closed.
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2007-03-05)
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2007-03-06)
Unknown
While I think the description of what to do when ECN is present is probably sufficiently clear to get the correct implementation, I did not understand the design rational as presented. The document says: 6.1.3. Explicit Congestion Notification (ECN) When ECN [RFC3168] is used once on a flow, the ECN bits could change quite often. ROHC-TCP maintains a control field in the context to indicate if ECN is used or not. This control field is transmitted in the dynamic chain of the TCP header, and its value can be updated using specific compressed headers carrying a 7-bit CRC. When this control field indicates that ECN is being used, items of IP and TCP headers in the irregular chain include bits used for ECN. To preserve octet-alignment, all of the TCP reserved bits are transmitted and, for outer IP headers, the entire TOS/TC field is included in the irregular chain. The design rationale behind this is the possible use of the "full- functionality option" of section 9.1 of [RFC3168]. Section 9.1 of RFC 3168 discusses how ECN interacts with IP tunnels. The two different behaviors are described there as: The result is that there are two viable options for the behavior of ECN-capable connections over an IP tunnel, including IPsec tunnels: * A limited-functionality option in which ECN is preserved in the inner header, but disabled in the outer header. The only mechanism available for signaling congestion occurring within the tunnel in this case is dropped packets. * A full-functionality option that supports ECN in both the inner and outer headers, and propagates congestion warnings from nodes within the tunnel to endpoints.: Does the author intend to make a parallel here between ROHC and IP tunnels, or is there an aspect of the design rational that needs further discussion?