Re: [tcpm] draft-ietf-tcpm-accurate-ecn-24 addressing all WGLC comments

[Markku Kojo <[e-mail]>]

Hi Michael, all,

On Sun, 14 May 2023, [e-mail] wrote:

>> On 30. Mar 2023, at 16:53, Bob Briscoe <[e-mail]> wrote:
>>
>> Michael, Yoshi, Ian (as tcpm chairs),
>>
>> To close off the WGLC, I have just posted a new rev of accurate-ecn. Hyperlinks quoted at the end.
>> You will see the diff is rather extensive. I won't give a summary of all the diffs like I usually do. Instead I can just refer to the summary I gave in the presentation on Monday:
>> https://datatracker.ietf.org/meeting/116/materials/slides-116-tcpm-draft-ietf-tcpm-accurate-ecn
>>
>> Thank you again to the people who reviewed this during the WGLC:
>> Michael Tüxen, Alex Burr, Gorry Fairhurst and Markku Kojo.
>>
>> All changes are editorial, apart from removing the para about not mistaking certain ACKs of ACKs for DupACKs, which I will add to a rev of the ECN++ draft, hopefully later this week.
>>
>> On the list, we have seen agreement from all the reviewers to these changes, except no response from Markku yet.
>> On Monday, I told Markku that I would post the draft in a few days, so everyone can see the updates and diff.
> Anyone having additional comments? In particular Markku regarding loss recovery?

My apologies for being late with my reply to the author's comments on my 
review (I've been extremly busy with other issues since the wg mtng in 
Yokohama, including the rest of mtng week).

I don't have much new comments but it seems that my major concern 
regarding the problem of sending ACKs of ACKs was not fully understood.

The first thing where I think I was not quite clear is that the major 
problem with ACKs of ACKs is not that a pure Ack is made ECN-capable. 
Instead, the problem is in generating an Ack of an pure Ack and that is 
what one should prohibit to avoid problems. I understand that it might be 
problematic to formulate rules whether generating an Ack of an Ack is 
allowed (and when), instead of just disabling sending ECN-capable ACKs.
I don't have a strong opinion which way the problems with ACKs of 
ACKs is avoided as long as they are avoided.

I am preparing a few scenarios to illustriate the problems ACKs of ACks 
raise and will send them shortly once I have formulated a more thorough 
reasoning why sending ACKs of ACKs is not really a good idea and even 
seems to be unnecessary in most if not all cases, i.e., it just results 
in sending unnecessary packets with not much useful effect but creates a 
notable number of problems. It also seems not have been carefully enough 
considered in terms of the very basic rubustness principle of "be 
conservative in what you send ..."

Given that this draft is intended to become a stds track RFC I am 
concerned of any text in this document that indicates (or even hints) 
that TCP could acknowledge pure ACKS (this holds particularly the 
rules and text in Sec 3.2.2.5.1 for the "Increment-Triggered ACKs"). If 
it is seen necessary that this doc should have such pieces of rules 
and text, I am fine if any such text is moved to an appendix as long as 
the appendix makes it cristal clear that the text is valid only in case 
one is implementing an experiment as per [I-D.ietf-tcpm-generalized-ecn].

Why?

1) It is well known that TCP does not acknowledge ACKs and Standards 
track TCP has not been specified to acknowledge ACKs. This means that a 
reader/implementer of this doc cannot correctly understand the rule for 
"Increment-Triggered ACKs" unless there is a normative reference to a 
spec that specifies ACKs of ACKs (or tells that it is even possible).

2) ACKs of ACKs tend to trigger duplicate Acks. There are tons of 
algorithms that rely on the packet conservation principle and the fact 
that TCP never injects a dupAck unless a *data* packet has arrived and 
left the network. This is enforced with "MUST NOT" in RFC 5681, Sec 4.2, 
because not conforming to this rule makes any algorithm that rely on the 
rule to work incorrectly. These algorithms include (triggering) Fast 
Retransmit, (controlling packet rate during) Fast Recovery, (detecting 
spurious RTOs in) F-RTO, (calculating PipeAck in) RFC 7661, 
(calculating DeliveredData in) PRR, etc. Furthermore, it would make 
imposible to come up with any new algorihms that rely on this important 
basic rule. In most cases such extra dupAcks make these algorithms too 
aggressive because any extra dupAck is likely to inject extra packet(s) to 
the network.

So, it should be cristal clear that without SACK (or Timestamps) a TCP 
*MUST NOT* send ACKs of ACKs.

3) Even with SACK or Timestamps enabled it is not clear what an
implementer should do. With SACK the AckECN authors seem to make an 
assumption, which seems obvious but is not, that an ACK of ACK would 
would never include SACK option and hence it could be distinguished from a 
dupAck. However, RFC 2018 specifies: "If sent at all, SACK options SHOULD 
be included in all ACKs which do not ACK the highest sequence number in 
the data receiver's queue. So, if there is a hole in the receiver's 
queue, the assumption is incorrect and it is unclear which SACK info 
to include into the SACK option. Whatever one selects to include, it makes 
DSACK (RFC 2883] void and breaks any DSACK-based algorithms unless RFC 
2018 is updated.

With Timestamps some algorithms like Eifel detection breaks. Moreover, 
there are other existing or potentially to-be-created heauristics, 
including various measurement tools, that rely on the fact that TCP does 
not echo a later Timestamp in a pure Ack than what arrived with the 
latest data packet. Any such mechanisms are subject to break.

It might be good to hold discussing any details on what breaks and how/why 
and what are the consequences until I have sent my reply with scenarios to 
Richard.

One additional comment regarding the "Change-Triggered ACKs" rule is that 
it would be useful to make it more clear how this plays with delayed Acks 
and how it alters acknowledgement rate.
I am not sure that what the draft currently says is quite correct:

  "The approach can lead to some additional ACKs but it feeds back
   the timing and the order in which ECN marks are received with minimal
   additional complexity. If CE marks are infrequent, as is the case for
   most AQMs at the time of writing, or there are multiple marks in a row,
   the additional load will be low.

For example, consider a scenario with bidirectional traffic between A 
and B where B has a hole in sequence resulting in every data packet in the 
current RTT to become acked (pure duplicate Acks). This may result in a 
packet flow from A to B where every second packet is a pure (duplicate) 
Ack. If there is congestion on the path from A to B such that a 
significant number of (data) packets get marked, it may result in acking 
every data packet from A to B. This does not necessarily result in low 
additional load?

Best regards,

/Markku


> Best regards
> Michael
>>
>> Cheers
>>
>>
>> Bob
>>
>> On 30/03/2023 15:15, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This Internet-Draft is a work item of the TCP Maintenance and
>>> Minor Extensions (TCPM) WG of the IETF.
>>>
>>>    Title           : More Accurate Explicit Congestion Notification (ECN) Feedback in TCP
>>>    Authors         : Bob Briscoe
>>>                      Mirja Kühlewind
>>>                      Richard Scheffenegger
>>>    Filename        : draft-ietf-tcpm-accurate-ecn-24.txt
>>>    Pages           : 64
>>>    Date            : 2023-03-30
>>>
>>> Abstract:
>>>    Explicit Congestion Notification (ECN) is a mechanism where network
>>>    nodes can mark IP packets instead of dropping them to indicate
>>>    incipient congestion to the endpoints.  Receivers with an ECN-capable
>>>    transport protocol feed back this information to the sender.  ECN was
>>>    originally specified for TCP in such a way that only one feedback
>>>    signal can be transmitted per Round-Trip Time (RTT).  Recent new TCP
>>>    mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP)
>>>    or Low Latency, Low Loss, and Scalable Throughput (L4S) need more
>>>    accurate ECN feedback information whenever more than one marking is
>>>    received in one RTT.  This document updates the original ECN
>>>    specification in RFC 3168 to specify a scheme that provides more than
>>>    one feedback signal per RTT in the TCP header.  Given TCP header
>>>    space is scarce, it allocates a reserved header bit previously
>>>    assigned to the ECN-Nonce.  It also overloads the two existing ECN
>>>    flags in the TCP header.  The resulting extra space is exploited to
>>>    feed back the IP-ECN field received during the 3-way handshake as
>>>    well.  Supplementary feedback information can optionally be provided
>>>    in two new TCP option alternatives, which are never used on the TCP
>>>    SYN.  The document also specifies the treatment of this updated TCP
>>>    wire protocol by middleboxes.
>>>
>>> The IETF datatracker status page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
>>>
>>> There is also an htmlized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-24
>>>
>>> A diff from the previous version is available at:
>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-accurate-ecn-24
>>>
>>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>
>
>