Skip to main content

RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)
RFC 4996

Yes

(Magnus Westerlund)

No Objection

Lars Eggert
(Bill Fenner)
(Cullen Jennings)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Sam Hartman)

Note: This ballot was opened for revision 16 and is now closed.

Lars Eggert No Objection

(Magnus Westerlund; former steering group member) Yes

Yes ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Brian Carpenter; former steering group member) No Objection

No Objection (2007-03-05)
From Gen-ART review by Miguel Garcia:

There's a reference to RFC 2001, which has been obsoleted by RFC 2581.

(Cullen Jennings; former steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Kessens; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Mark Townsley; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sam Hartman; former steering group member) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection (2007-03-06)
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?