Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-16.txt

[Vidhi Goel <[e-mail]>]

Hello Bob and authors,

I have read the draft a few times and will send my extensive review at a later point. But right now, I want to ask some critical things that an implementation could benefit from.

The draft says,
If a TCP client has set the SYN to Not-ECT, but
   receives feedback that the IP-ECN field on the SYN arrived with a
   different codepoint, it can detect such middlebox interference and
   send Not-ECT for the rest of the connection

1. On the forward path from client to server, the client will revert to Not-ECT when it sees for example, that it sent a Non-ECT SYN but received ACE encoding other than 0 1 0. What does the client do in the last ACK of the 3WHS -
 a. does it stay in AccECN mode and still send AccECN encoding based on the IP code point of SYN-ACK (Table 4)? This would mean that client won’t participate in ECN on the sender half of the connection and only provide AccECN feedback to the server as a receiver.
 b.  does it disable AccECN mode and set ACE= 0 0 0 so that a server in AccECN mode can disable ECN based on Table4?

While writing this, I realized that the intention is probably a. Could you confirm? Also, when the sender sets Not-ECT in its data packets, it should also disable acting upon any ACE feedback as we could still receive false ACE feedback from the server if the network, lets say, changed 00 (not ECT) to 01(ECT1). If you agree, we should add some text around this. Based on the current text, the sender will always respond to the ACE feedback even if it sends Not-ECT.

TBH, this is a complicated scenario, where sender said to the network - I don’t trust you so I can’t use ECN. Feel free to drop my packets. And the network mangles the IP to ECT1 and then set CE (when congested) which would be feedback’ed from the receiver. Now, the packet wasn’t dropped which it should have been. So, is it better to just ignore this feedback because sender doesn’t trust the network or just act on it and reduce cwnd in order to reduce congestion in the network somewhere.

2. On the reverse path from server to client, if a server sends a Not-ECT SYN-ACK and receives ACE handshake encoding on last ACK other than 0 1 0, there is no text like above that says server should send Not-ECT for the rest of the connection (or at least I didn’t find it). I think the server should also do same as client as the two paths could be different. One could make it more complicated by saying, if both client and server decide to not use ECN on their corresponding sender half, then ECN should be disabled but let’s talk about that later.

3. In general, not setting the ECT (ECT0 or ECT1) code point on an outgoing packet is different from supporting AccECN right as in the host can still provide AccECN feedback on the receive path.
….

To be continued if more questions come to my mind.


Thanks,
Vidhi

> On Feb 3, 2022, at 7:24 AM, Bob Briscoe <[e-mail]> wrote:
> 
> tcpm folks,
> 
> This rev to accurate-ecn is the first of two. The second will hopefully follow on its heels in the next couple of days.
> 
> Diffs between this first rev (-16) and -15:
> 
> 1.  switches round two fairly large sections, so I've deferred other changes to a second rev so the diffs won't be masked by the switch round of sections.
> Suggested by Ilpo to match the order in which the tests in these sections will be executed:
> * Test for mangling the IP-ECN field (now 3.2.2.3),
> * Then test for zeroing the ACE field (now 3.2.2.4).
> 
> 2. Ilpo suggested some clarifications in "3.2.3.2.5.  Consistency between AccECN Feedback Fields", which is about the receiver of feedback ensuring consistency between the mandatory 3-bit ACE field and the optional 24-bit counters. In brief (paraphrasing) it previously only said "MUST consider both fields", when it is now clearer that it actually meant "MUST reconcile both fields", so that there is always a consistent baseline for subsequent ACKs.
> 
> 3. A minor point is added in an appendix about the details that the pseudocode doesn't cover.
> 
> 
> 
> Bob
> 
> PS. #2 & #3 were added to the XML ages ago (Jul '21), so you will have seen them in the HTML. However, prob due to my clumsiness, the posted TXT didn't include them whereas the posted XML did (ironic for a section about consistency). In turn, inconsistency was only possible because I am having to manually post the TXT for this draft, due to an unresolved issue with v3 RFC XML tables.
> 
> 
> On 03/02/2022 14:43, [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>> 
>>         Title           : More Accurate ECN Feedback in TCP
>>         Authors         : Bob Briscoe
>>                           Mirja Kühlewind
>>                           Richard Scheffenegger
>> 	Filename        : draft-ietf-tcpm-accurate-ecn-16.txt
>> 	Pages           : 60
>> 	Date            : 2022-02-03
>> 
>> 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 end-points.  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 Scalable Throughput (L4S) need more
>>    accurate ECN feedback information whenever more than one marking is
>>    received in one RTT.  This document specifies a scheme to provide
>>    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 a new TCP option, which is 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 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-16
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-16
>> 
>> 
>> 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/
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm