[tcpm] FW: Review of draft-bagnulo-tcpm-generalized-ecn (David Black)

["Black, David" <[e-mail]>]

I sent this review to the draft authors privately, and they asked that I forward to the TCPM list; this version had been edited slightly from what I sent to the draft authors.  Please cc: me directly on any responses or follow-up emails, as I'm not currently on the TCPM list.

In general, I think this draft is headed in the right direction.  I've limited this review to items with at least moderate technical impact.  I apologize that it's taken over 4 months to get this review done - the day job has been putting much more pressure on my IETF activity that expected since the start of this year.

Overall concern: Abstract and Introduction should make it clear  that this draft is primarily about Accurate ECN, with applicability to vanilla RFC 3168 ECN being an open question for further discussion.  It's also not clear to me whether applicability to vanilla RFC 3168 ECN is a single global decision for all packet types vs. a per-packet-type decision.

-- Section 1.3

OLD
   RFC3168 does not prevents from using ECN in TCP
   control packets lightly.  It provides a number of specific reasons
   for each packet type.  In this Section 4, we revisit each of the
   arguments provided by RFC3168 and explore possibilities to enable the
   ECN capability in the different packet types.
NEW
   RFC3168 does not prohibit use of ECN for TCP
   control packets lightly.  It provides a number of specific reasons why
   ECN should not be used for each packet type.  In this Section 4, we analyze
   each of the reasons provided by RFC3168 as part of explaining why this
   experiment is reasonable to conduct for each of the different packet types.

Last sentence in old text is too weak - "explore possibilities" doesn't sound like providing a solid rationale for experimentation.

-- Section 2

OLD
   Retransmission: A TCP segment that has been retransmitted by the TCP
   sender because it determined that the original segment was lost,
   which may or may not be the case.
NEW
   Retransmission: A TCP segment that has been retransmitted by the TCP
   sender.

Shortened definition to improve clarity.

-- Section 3.1

This section is problematic as written, as it appears to require a router to parse TCP packets and maintain enough state to detect retransmissions.  That's surely not what was intended ;-).   This section should be rewritten and dramatically shorted to require that routers treat ECT-marked TCP control packets and retransmissions just like any other ECT-marked packet, as specified in RFC 3168 (and don't repeat lengthy RFC 3168 text here).

The reason to rewrite this section to point to RFC 3168 is that any divergence from RFC 3168 network node behavior for other ECT-marked packets is likely to not only be a bad idea, but to also be fatal to this proposal.  It's ok to cite RFCs beyond 3168 if needed to specify  the network node behavior.

-- Section 3.2.1.1

   The server SHOULD not set any of the ECT codepoints if
   the server is included in the cache as not supporting ECN in the SYN
   packet.

Which cache?  The natural reading of this text is "the client's cache" in which case this requirement is unimplementable as written because the server can't see the client's cache.  I suspect that the actual requirement is that the server not change its ECN behavior until any client cache entry for it is certain to have aged out (how long would that be? provide an answer ...).   There appears to be an analogous concern with the server cache in 3.2.1.2.

--Section 3.2.2.1

   Also, it should be noted than if an ACK
   is dropped due to congestion the sender of the ACK does not react by
   reducing the load in any way.

Given that statement, much of the discussion of how to reduce sender load on the network may be irrelevant.   In the quoted sentence, at  least the first instance of "ACK" should be "pure ACK".

-- Section 3.2.3.1

I think the reduction in offered load discussion in this section is pointless; the sender should behave as if the Zero Window Probe were dropped.

-- End of Section 3.2

This would be a good place to summarize sender and receiver behavior changes.  That summary is needed anyhow, as the changes to RFC 3168 need to be clearly called out, and preferably summarized in one place.

-- Section 4.1

   In particular, setting the CE
   codepoint in the very same packet seem to fulfill this criteria,
   since either the packet is delivered and the CE codepoint signal is
   delivered to the endpoint, or the packet is dropped, so the original
   congestion signal through the packet loss is delivered to the
   endpoint.

That assumes that "the very same packet" will be retransmitted, which is correct for data packets, but not control packets (e.g., a pure ACK  or a zero window probe).  What may be missing (or not well stated in the rest of this paragraph) is that drops of these packets don't cause congestion reactions. 

   As currently specified, ECN adoption implies an increased reliability
   of the ECN congestion signal and a decrease in the reliability in the
   TCP control packets.  We believe that it is possible and desirable to
   restore the tradeoff existent in non ECN capable networks in terms of
   reliability, where the congestion signal delivery is as reliable as
   in a non ECN capable network and so it is the delivery of TCP control
   packets.

Add a section reference for decrease in reliability - to Section 1.1 ??

Thanks, --David
--------------------------------------------------------
David L. Black, Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
[phone]     Cell: [phone]
[e-mail]  <=== NEW ===
--------------------------------------------------------