On Jan 27, 2025, at 11:59, The IESG <iesg-secretary@xxxxxxxx> wrote:
> The IESG has received a request from the TCP Maintenance and Minor Extensions
> WG (tcpm) to consider the following document: - 'More Accurate Explicit
> Congestion Notification (ECN) Feedback in TCP'
> <draft-ietf-tcpm-accurate-ecn-31.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@xxxxxxxx mailing lists by 2025-02-10. Exceptionally, comments may
> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
I will begin by repeating the comment I wrote previously, last July.
Congratulations and thanks to the authors for an excellent document.
The idea of Accurate ECN could be described in one page; the rest of the document is a very thorough analysis of all the forwards- and backwards-compatibility issues -- legacy servers that don’t support Accurate ECN, buggy servers that don’t even implement classic ECN negotiation properly, poorly designed middleboxes that try to “help” TCP connections and actually mess them up.
This draft dates back to draft-kuehlewind-tcpm-accurate-ecn-00 in 2011. It is long overdue that we get it published. Apple has implemented Accurate ECN. Wireshark correctly decodes Accurate ECN. We’d love to see Accurate ECN supported in mainline Linux too, but the Linux networking maintainers are quite reasonably cautious about what they put in the Linux networking code. They want to see a Standards-Track RFC that shows it has received IETF review and consensus.
CableLabs and Comcast are rolling out L4S, but to use L4S, TCP needs Accurate ECN. A lot of good progress has been made here, but we’re starting to see further progress being held up by the lack of RFC publication for Accurate ECN. I’m very glad to see this document has made it to the final stages.
Further comments are below. Mainly they are suggestions for editorial tweaks to improve readability.
1. Introduction text
I suggest a sentence or two in the introduction to help dispel the common myth that “congestion control” is something that is no longer needed because “there isn’t congestion on the Internet anymore”. I would say something like, “congestion control is the term the IETF uses to describe data rate management; it is the algorithm that a sender uses to optimize its sending rate so that it sends data as fast as the network can carry it, but no faster.”
2. Payload bytes
For the byte counters in the AccECN Options the document says that they count payload bytes. I *think* I know what “payload bytes” means, but for clarity it would be good for the document to state explicitly that these byte counters reflect only the TCP segment length -- they do not include the Ethernet header, the IP header, the TCP header, or TCP options. A reader could be confused about this, since all those headers do contribute to the amount of network capacity that is consumed. A TCP pure ack with zero bytes of segment length does not consume zero bytes of network capacity.
3. Testing for Zeroing of the ACE Field
The possibility of re-ordering means that there is a small chance
that the ACE field on the first packet to arrive is genuinely zero
(without middlebox interference). This would cause a host to
unnecessarily disable ECN for a half connection. Therefore, in
environments where there is no evidence of the ACE field being
zeroed, implementations can skip this test.
I have reservations about this test. The idea that this heuristic might suffer from false positives and falsely disable Accurate ECN for no good reason worries me. A user is expecting the low-latency benefits of L4S and Accurate ECN, and then though no fault of their own sometimes does not get these benefits. I also have mixed feelings about the trade-off that is implicit here: If there are defective middleboxes on the path, would we like to see these middleboxes fixed, or do we want to enable them to remain broken in perpetuity (to the detriment of all the people unfortunate enough to have their traffic traverse those defective middleboxes)?
Knowing what we know now in 2025, is this zero-ACE-field check still necessary? I would hate to have a heuristic designed to work around failures of the past end up becoming a liability that causes a new set of unpredictable failures indefinitely into the future.
4. Packet Receiver Safety Procedures
Increment-Triggered ACKs: An AccECN receiver of a packet MUST emit
an ACK if 'n' CE marks have arrived since the previous ACK. If
there is unacknowledged data at the receiver, 'n' SHOULD be 2. If
there is no unacknowledged data at the receiver, 'n' SHOULD be 3
and MUST be no less than 3. In either case, 'n' MUST be no
greater than 7.
Which direction? Does “unacknowledged data at the receiver” mean data that the receiver has *received* but not yet sent an acknowledgement for, or data that the receiver has *sent* but not yet received an acknowledgement for?
If the arrivals of a number of data packets are all processed as one
event, e.g. using large receive offload (LRO) or generic receive
offload (GRO), both the above rules SHOULD be interpreted as
requiring multiple ACKs to be emitted back-to-back (for each
transition and for each repetition by 'n' CE marks).
The phrase “for each repetition by 'n' CE marks” seems odd to me. How about one of the following?
for each repetition of 'n' CE marks
for each run of 'n' CE marks
for each sequence of 'n' CE marks
5. Usage of the AccECN TCP Option
Necessary Option Length: The Data Receiver MUST only include an
AccECN TCP Option on a packet if it includes all the counter(s)
that have incremented since the previous AccECN Option. It MUST
only truncate unchanged fields from the right-hand tail of the
option to preserve the order of the remaining fields (see
Section 3.2.3);
I think I understand what this is saying, but the text is not quite accurate. It is not sufficient merely to preserve the *order* of the remaining fields; the actual *location* of the fields within the option must be preserved. How about this?
Necessary Option Length:
When TCP option space is limited, an AccECN TCP Option
MAY be truncated to omit one or more fields from the end
of the option, as indicated by the permitted variants
listed in Table 5, provided that counter(s) that have
changed since the previous AccECN Option are not omitted.
If there is insufficient space to include an AccECN TCP Option
containing all the counter(s) have changed since the previous
AccECN Option, then the entire AccECN Option MUST be omitted.
6. Punctuation
* It SHOULD, include each counter at least once for every 2^22
Delete the comma.
Also I see a number of places in the document that use a backtick instead of an opening quotation mark. <https://en.wikipedia.org/wiki/Backtick>
If we want to use proper typographical quotes (which I definitely support), let’s use the actual Unicode characters for those:
U+2018 ‘
U+2019 ’
U+201C “
U+201D ”
7. TCP Normalizers
A middlebox that is not normalizing the TCP protocol ...
Using the term “normalize” seems too generous to these types of devices, that are made to prevent deployment of anything the designer did not understand, including preventing any future improvements to a protocol.
How about using one of these terms instead of “normalizer”?
TCP limiter
TCP inhibitor
TCP restrictor
TCP constrainer
8. Wording
given outdated normalizers would block updated hosts from
using the extended AccECN standard
What does the word “given” mean here? Perhaps it might be better to say:
such outdated normalizers would block updated hosts from
using the extended AccECN standard
9. Requirements for TCP Segmentation Offload
The text of this section talks about *both* TCP Segmentation Offload (TSO) and Large Receive Offload (LRO). Maybe the heading should be:
Requirements for TSO and LRO
10. newlyAckedPkt wrongly estimated
The document says:
Note that checks would need to be added to the above pseudocode for
(d.cep > newlyAckedPkt), which could occur if newlyAckedPkt had been
wrongly estimated using an inappropriate packet size.
Is it possible to explain this a little more? It seems odd to give pseudocode and then immediately state that the given pseudocode is inadequate.
11. Reference-as-noun
I have a final request, which I think improves the readability of documents, and that is to avoid using reference-as-noun. It is quite common in many IETF documents for the people writing the documents to assume that the person reading the document has all the same RFC numbers memorized, and merely including an RFC number in square brackets is sufficient for the reader to know exactly what you’re talking about. In reality those numbers are pretty meaningless to most readers, which makes the resulting sentence pretty incomprehensible to most readers. The result is that readers constantly have to flip back and forth to the references section to decode the meaning of a sentence. Below is one little example snippet from the document, edited to reflect how it appears to a typical reader:
For congestion response, this
specification refers to [somedoc], as updated to allow ECN
experiments like those referred to in [otherdoc] ...
I find it be a useful technique to improve the readability of a document if I (i) delete the references, (ii) fix the resulting text to make sure that the sentences actually make sense, then (iii) add back the references as appropriate. Remember that before we used typewriters, academic papers were typeset with references as little superscript numbers, and nobody made the mistake of thinking those little superscript numbers were a substitute for actual English words. Following this readability technique, the text snippet could become something like this:
For congestion response, this specification refers to the
original 2001 classic ECN specification [RFC3168], as updated
by the more relaxed rules introduced in 2018 [RFC8311] ...
For another example, this:
Initially, when [ref] and Accurate ECN flows coexist
would be clearer if rewritten as:
Initially, when Classic ECN [ref] and Accurate ECN flows coexist
Stuart Cheshire
P.S. Are the TCP option codes 172 and 174 fixed now and not subject to change? (I hope so, because that’s what Apple has implemented.)
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
