Authors,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the XML file.
1) <!-- [rfced] Because these documents are defined in Informational RFCs,
is "proposed" needed here?
Original:
Recently, proposed mechanisms like Congestion Exposure (ConEx
[RFC7713]), DCTCP [RFC8257] or L4S [RFC9330] need to know when more
than one marking is received in one RTT, which is information that
cannot be provided by the feedback scheme as specified in [RFC3168].
Perhaps:
Newer mechanisms like Congestion Exposure (ConEx
[RFC7713]), DCTCP [RFC8257], or L4S [RFC9330] ...
Or perhaps, "More recently defined mechanisms ..."
-->
2) <!-- [rfced] We are having trouble parsing "extent of congestion
notification". Perhaps this means "indicate the amount of congestion over
the round trip"? Please clarify.
Original:
Or, unlike Reno or
CUBIC, AccECN can be used to respond to the extent of congestion
notification over a round trip, as for example DCTCP does in
controlled environments [RFC8257].
-->
3) <!-- [rfced] Because "Reserved combination" is not used much, would it
help the reader to add a pointer - perhaps to table 2?
Original:
All these requirements ensure that future uses of all the Reserved
combinations on a SYN or SYN/ACK can rely on consistent behaviour
from the installed base of AccECN implementations. See Appendix B.3
for related discussion.
-->
4) <!-- [rfced] Should a second closing parens appear after "congestion)"?
Original:
Implementers MAY use other fall-back strategies if they are found to
be more effective (e.g., attempting to negotiate AccECN on the SYN
only once or more than twice (most appropriate during high levels of
congestion).
-->
5) <!-- [rfced] We are unsure what "try it without" refers to here. Is it
"advisable to experiment without using the ECT on a SYN"?
Original (sentence prior included for context):
Further it might make sense to also remove any other new or
experimental fields or options on the SYN in case a middlebox might
be blocking them, although the required behaviour will depend on the
specification of the other option(s) and any attempt to co-ordinate
fall-back between different modules of the stack. For instance, even
if taking part in an [RFC8311] experiment that allows ECT on a SYN,
it would be advisable to try it without.
-->
6) <!-- [rfced] Throughout, some of the bulleted lists use a mix of periods and
semicolons to close the item - some within the same list. Please consider
whether
these may be updated for consistency. We recommend using terminating periods,
unless the goal is to clarify an "and" or "or" connection between the list
items.
Please review.
-->
7) <!-- [rfced] For clarity, we'd like to add quotes to "handshake encoding".
Please confirm this is correct, as opposed to "handshake encoding of the ACE
field".
Original:
This shall be called the handshake encoding of the ACE
field, and it is the only exception to the rule that the ACE field
carries the 3 least significant bits of the r.cep counter on packets
with SYN=0.
-->
8) <!-- [rfced] For readability, may we break this text into two sentences?
Original:
When an AccECN Server in SYN-RCVD state receives a pure ACK with
SYN=0 and no SACK blocks, instead of treating the ACE field as a
counter, it MUST infer the meaning of each possible value of the ACE
field from Table 4, which also shows the value that an AccECN Server
MUST set s.cep to as a result.
Perhaps:
When an AccECN Server in SYN-RCVD state receives a pure ACK with
SYN=0 and no SACK blocks, it MUST infer the meaning of each possible
value of the ACE field from Table 4 instead of treating the ACE field
as a counter. Table 4 also shows the value to which an AccECN Server
MUST set s.cep as a result.
-->
9) <!-- [rfced] We are unclear what "it" refers to in the following. Perhaps
"it"
can be deleted?
Original:
Given this encoding of the ACE field on the ACK of a SYN/ACK is
exceptional, an AccECN Server using large receive offload (LRO) might
prefer to disable LRO until such an ACK has transitioned it out of
SYN-RCVD state.
-->
10) <!-- [rfced] We converted the notes following Table 4 into a list for
clarity.
Please let us know if you have any concerns.
-->
11) <!-- [rfced] We are having trouble parsing "depend on experience of the
most
likely scenarios". Does it depend on how good the experience is, the outcome,
etc? Please consider whether this text can be clarified.
Original:
This advice is not stated normatively (in capitals), because the best
strategy might depend on experience of the most likely scenarios,
which can only be known at the time of deployment.
-->
12) <!-- [rfced] Where is "below these bullets", as we don't see a bulletized
list
in Section 3.2.2.5.1? If possible, we recommend adding a pointer for clarity.
Original:
Even though this rule is stated as a "SHOULD", it is important for
a transition to trigger an ACK if at all possible, The only valid
exception to this rule is given below these bullets.
-->
13) <!-- [rfced] For ease of the reader, we suggest adding a pointer to the
examples.
Original:
Recommended Simple Scheme: The Data Receiver SHOULD include an
AccECN TCP Option on every scheduled ACK if any byte counter has
incremented since the last ACK. Whenever possible, it SHOULD
include a field for every byte counter that has changed at some
time during the connection (see examples later).
-->
14) <!-- [rfced] Mention of BCP 69 was removed to the HTML and PDF could link
directly to Section 5.2.1 of RFC 3449. Would you prefer that BCP 69 be
included
as the cite tag?
Original:
Section 5.2.1 of BCP 69 [RFC3449] gives best current practice on
filtering (aka. thinning or coalescing) of pure TCP ACKs.
Perhaps:
Section 5.2.1 of RFC 3449 [BCP69] gives best current practice on
filtering (aka thinning or coalescing) of pure TCP ACKs.
-->
15) <!-- [rfced] Does "even if it is" refer to using AccECN without ECN++ or
with
ECN++?
Original:
However, it might omit some AccECN ACKs, because
AccECN can be used without ECN++ and even if it is, ECN++ does not
have to make pure ACKs ECN-capable - only deployment experience
will tell.
Perhaps:
However, it might omit some AccECN ACKs because
AccECN can be used without ECN++. Even if ECN++ is used, it does not
have to make pure ACKs ECN-capable - only deployment experience
will tell.
-->
16) <!-- [rfced] Instead of using [RFC3168] as an adjective, may we update this
text to refer to "Classic ECN"?
Original:
One way around this could be to only negotiate for Accurate ECN, but
not offer a fall back to [RFC3168] ECN.
Perhaps:
One way around this could be to only negotiate for Accurate ECN, but
not offer a fall back to Classic ECN [RFC3168].
Original:
For LRO in the receive direction, a different issue may get exposed
with [RFC3168] ECN supporting hardware.
Perhaps:
For LRO in the receive direction, a different issue may get exposed
with Classic-ECN [RFC3168] supporting hardware.
-->
17) <!-- [rfced] Throughout: We have removed the section titles and linked the
section numbers directly to the section of the RFC specified. For example, the
text has been updated as follows:
Original:
* The whole of "6.1.1 TCP Initialization" of [RFC3168] is updated by
Section 3.1 of the present specification.
Current:
* The whole of Section 6.1.1 of [RFC3168] is updated by Section 3.1
of the present specification.
In the HTML and PDF files, "Section 6.1.1 links to Section 6.1.1 of RFC 3168.
Please review and let us know if you prefer the section titles be included.
-->
18) <!-- [rfced] We are unclear why "potentially updates" is mentioned here.
Is
it mentioned to cover implementations of RFC 3168 have not been updated yet
and/or
potential future updates? Otherwise, may it be cut?
Original:
It will be noted that RFC 8311 already updates, or potentially
updates, a number of the requirements in "6.1.2. The TCP Sender".
-->
19) <!-- [rfced] As we believe "pressure" refers to options vying for limited
space, perhaps this update would be more clear?
Original:
When option space is under pressure from other options,
Section 3.2.3.3 provides guidance on how important it is to send an
AccECN Option relative to other options, and which fields are more
important to include.
Perhaps:
Because option space is limited, Section 3.2.3.3 provides guidance on
how important it is to send an AccECN Option relative to other options
and specifies which fields are more important to include.
-->
20) <!-- [rfced] Please confirm "experimental" is correct here. We ask because
RFC 7713 is an Informational RFC.
Original:
ConEx is an experimental change to the Data Sender that would be
most useful when combined with AccECN.
-->
21) <!-- [rfced] We have updated the registry title per the note below
from IANA. While draft-ietf-tsvwg-udp-options has not yet been published,
this title matches what currently appears on the IANA site. Please let us
know any concerns.
NOTE: The name of the registry called "TCP Experimental Option Experiment
Identifiers (TCP ExIDs)" in the IANA Considerations section has been changed to
"TCP/UDP Experimental Option Experiment Identifiers (TCP/UDP ExIDs)," per
draft-ietf-tsvwg-udp-options-45.
Original:
Early experimental implementations of the two AccECN Options used
experimental option 254 per [RFC6994] with the 16-bit magic numbers
0xACC0 and 0xACC1 respectively for Order 0 and 1, as allocated in the
IANA "TCP Experimental Option Experiment Identifiers (TCP ExIDs)"
registry.
-->
22) <!-- [rfced] Please consider whether the placement of B at the end
of the sentence is correct.
Original:
This opens up a potential covert channel of up to 29B (40 -
(2+3*3)) B.
-->
23) <!-- [rfced] This sentence reads a bit awkwardly. Perhaps this can
be rephrased?
Original:
No known way can yet be contrived for a receiver to take
advantage of this behaviour, which seems to always degrade its own
performance.
Perhaps:
Currently, there is no known way for a receiver to take
advantage of this behaviour, which seems to always degrade its own
performance.
-->
24) <!-- [rfced] Instead of "show up more easily", perhaps "be more
easily identified" would improve readability?
Original:
A generic privacy concern of any new protocol is that for a while it
will be used by a small population of hosts, and thus show up more
easily.
-->
25) <!-- [rfced] We have updated the text as shown below. Please let us
know any concerns.
Original:
However, it is expected that this option will become
available in operating systems over time, and eventually turned on by
default in them.
Current:
However, it is expected that AccECN will become
available in operating systems over time and that it will eventually
be turned on by default.
-->
26) <!-- [rfced] [RoCEv2]
Please review. We could not confirm the Volume or Release number for
this reference. Note that there is information at the current URL which mentions
"Volume 1 Release 1.8" (see:
https://www.infinibandta.org/wp-content/uploads/2024/09/IBTA-Overview-of-IBTA-Volume-1-Release-1.8.pdf).
Would you like us to update this reference to Release 1.8, use a
version-less reference, or keep the Release 1.4 version of the reference?
Current:
[RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture
Specification", Volume 1, Release 1.4, 2020,
<https://www.infinibandta.org/ibta-specification/>.
Perhaps:
[RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture
Specification",
<https://www.infinibandta.org/ibta-specification/>.
OR
[RoCEv2] InfiniBand Trade Association, "InfiniBand Architecture
Specification", Volume 1, Release 1.8, July 2024,
<https://www.infinibandta.org/ibta-specification/>.
-->
27) <!-- [rfced] May we update "implement" to "satisfy" to clarify the text and
avoid "implementers implement"?
Original:
However, implementers are free to choose other ways
to implement the requirements.
-->
28) <!-- [rfced] The following note was included in the XML.
ToDo: Note to RFC Editor: Pls change all bare <artwork> elements (without
any keywords like align) to <sourcecode>.
Reason My XML editor doesn't support the <sourcecode> element, so it mangles
line
breaks within sourcecode, ignoring even CDATA protection.
We have updated the XML file as noted. Please let us know how/if he "type"
attribute of each sourcecode element should be set. Perhaps some/all should be
marked as pseudocode?
If the current list of preferred values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
-->
29) <!-- [rfced] We are having trouble parsing this sentence. Where does the
"which" statement end - after "full-sized"? Does "it" refer to the algorithm?
Original:
However, we shall start
with the simplest algorithm, which assumes segments are all full-
sized and ultra-conservatively it assumes that ECN marking was 100%
on the forward path when ACKs on the reverse path started to all be
dropped.
-->
30) <!-- [rfced] May we change "works out" to "indicates" or "determines"?
Original:
The above formula works out that it
would still be safe to assume 2 CE marks (because 9 - ((9-2) % 8) =
2).
-->
31) <!-- [rfced] Does "5% of full-sized" mean segments are "5% of their full
size"? May we change "as long as" to "while" for readability?
Original:
The simple algorithm for dSafer.cep above requires no monitoring of
prevailing conditions and it would still be safe if, for example,
segments were on average at least 5% of full-sized as long as ECN
marking was 5% or less.
-->
32) <!-- [rfced] We updated the text to point directly to Section 3.2.2.5.2
(where the quoted text appears). Please let us know any concerns.
Original:
If missing acknowledgement numbers arrive later (due to reordering),
Section 3.2.2.5 says "the Data Sender MAY attempt to neutralize the
effect of any action it took based on a conservative assumption that
it later found to be incorrect".
-->
33) <!-- [rfced] We are having trouble parsing "will consider d.cep can
replace".
Please clarify.
Original:
The chart below shows when the above algorithm will consider d.cep
can replace dSafer.cep as a safe enough estimate of the number of CE-
marked packets:
Perhaps:
The chart below shows when the above algorithm will consider the number
of CE-marked packets as a safe enough estimate to replace dsafer.cep
with d.cep.
-->
34) <!-- [rfced] To what does "this" refer - the ACK? The sentence prior is
included for context.
Original:
If AccECN Options are not available, the Data Sender can only decode
CE-marking from the ACE field in packets. Every time an ACK arrives,
to convert this into an estimate of CE-marked bytes, it needs an
average of the segment size, s_ave.
-->
35) <!-- [rfced] Does "earlier versions" refer to earlier draft versions of
this
document?
Original:
This development consumed the remaining 2 codepoints
on the SYN/ACK that had been reserved for future use by AccECN in
earlier versions.
-->
36) <!-- [rfced] Please review the following terminology-related questions.
A) We updated the following to the form on the right. Please let us know if
any
corrections are needed.
not-ECT vs Not-ECT
no ECN vs No ECN
ECN Nonce vs ECN-Nonce vs ECN nonce (to match RFC 3540)
Cubic vs CUBIC (to match RFC 9438)
IP ECN field vs IP-ECN field
ECN capable vs ECN-capable (to match RFC 3168, though we wonder if it should be
open (ECN capable) when not acting as an adjective appearing before then noun.
time-out vs timeout
CE mark* vs CE-mark* - updated to use the hyphen when acting as an adjective
appearing before the noun
B) Please review occurrences of the terms below and let us know if/how they may
be made consistent.
TCP Option vs TCP option (perhaps TCP Option when referring to a specific
option?)
Established state vs established state vs ESTABLISHED state
half connection vs half-connection
C) We note that "time-stamp" is used consistently. However, RFC 7323 uses
"timestamp". May we update the text for consistency?
-->
37) <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
38) <!-- [rfced] Some author comments are present in the XML. Please confirm
that no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
39) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
RFC Editor
On Aug 12, 2025, at 12:31 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/08/12
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9768.xml
https://www.rfc-editor.org/authors/rfc9768.html
https://www.rfc-editor.org/authors/rfc9768.pdf
https://www.rfc-editor.org/authors/rfc9768.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9768-diff.html
https://www.rfc-editor.org/authors/rfc9768-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9768-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9768
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9768 (draft-ietf-tcpm-accurate-ecn-34)
Title : More Accurate Explicit Congestion Notification (AccECN)
Feedback in TCP
Author(s) : B. Briscoe, M. Kühlewind, R. Scheffenegger
WG Chair(s) : Yoshifumi Nishida, Michael Tüxen
Area Director(s) : Gorry Fairhurst, Mike Bishop
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
