Re: [tcpm] [tsvwg] draft-ietf-tsvwg-ecn-l4s-id question

["Klatsky, Carl" <[e-mail]>]

Bob,

Thanks for looping in tcpm, and thanks for the clarification.  I’ll let this sink in some more, but good for now.

Regards,
Carl Klatsky

From: Bob Briscoe <[e-mail]>
Sent: Monday, August 8, 2022 9:48 AM
To: Klatsky, Carl <[e-mail]>; [e-mail]
Cc: tcpm IETF list <[e-mail]>
Subject: Re: [tsvwg] draft-ietf-tsvwg-ecn-l4s-id question

Karl, See BB inline, [I've added tcpm to the distro]
On 04/08/2022 16:54, Klatsky, Carl wrote:
Hello tsvwg-ecn-l4s-id authors,

Question on this part fron section 4.2

   TCP:  Support for the accurate ECN feedback requirements [RFC7560]
      (such as that provided by AccECN [I-D.ietf-tcpm-accurate-ecn]) by
      both ends is a prerequisite for scalable congestion control in
      TCP.  Therefore, the presence of ECT(1) in the IP headers even in
      one direction of a TCP connection will imply that both ends
      support accurate ECN feedback.  However, the converse does not
      apply.  So even if both ends support AccECN, either of the two
      ends can choose not to use a scalable congestion control, whatever
      the other end's choice.

I follow the comment about the converse case where both ends support AccECN but decide not to use it.  Is there ever a case where both ends support AccECN and negotiate it per table 2 in tcpm-accuarte-ecn, yet do not set ECT(1) in the IP header for some reason, but then will respond if they see CE set on packets by the bottleneck link entity?  Trying to understand if this is possible, and if possible is it likely to occur or just hypothetical.  Thanks.

[BB] This is perfectly possible, because the idea is that Accurate ECN TCP feedback (AccECN) provides a superset of both Accurate and Classic ECN feedback. Meaning, AccECN supports the same API to the feedback of a CE event as was there with RFC3168 ECN feedback.

So, if both ends have an updated kernel that supports AccECN, and both ends have loaded a Classic (non-L4S) congestion control module (e.g. CUBIC) with ECN support, then they would negotiate to use AccECN at the TCP layer and both send ECT(0) packets at the IP layer. Then, if a CE arrived at the data receiver, it would feed it back using AccECN's ACE counter (and optionally the AccECN TCP options), and the data sender would detect an increase in the counter, so the CUBIC module would trigger CUBIC's window decrease and ignore all further increases to AccECN's counters for the next round trip.

If AccECN became supported by default in some OSs, this could become a very likely case, at least while CUBIC is the default congestion control for most OSs.

Another possible case would be that both ends support AccECN, one has an L4S CC module loaded (e.g. Prague) and the other has a Classic CC module loaded (e.g. CUBIC). Then the packets in one direction would all be set to ECT(1) while the data packet in the other direction would be set to ECT(0) while the TCP control packets (SYN, SYN-ACK, pure ACKs, retransmissions) would be zeroed to Not-ECT.

I used to always include a diagram in the spare slides of every AccECN presentation explaining where it fits in the stack. But the last time I did was Nov'21 (see the last slide here):
    https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-more-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notification-01#page=12<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-more-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notification-01*page=12__;Iw!!CQl3mcHX2A!BIyJSwIY_9jS0cyujIfH4xcSiwFznpFqVDVTmyjVCn1PV1pXazdCloL-JHCzUt0kPY1gXSpwoMqm0eSIGQ$>
This may or may not help!

The introduction of the AccECN spec should also help. But if you can suggest any better ways of saying it, or any gaps in what it says, pls do.
    https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-20__;!!CQl3mcHX2A!BIyJSwIY_9jS0cyujIfH4xcSiwFznpFqVDVTmyjVCn1PV1pXazdCloL-JHCzUt0kPY1gXSpwoMqtw4rRbQ$>

Cheers


Bob



Regards,
Carl Klatsky




--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://urldefense.com/v3/__http:/bobbriscoe.net/__;!!CQl3mcHX2A!BIyJSwIY_9jS0cyujIfH4xcSiwFznpFqVDVTmyjVCn1PV1pXazdCloL-JHCzUt0kPY1gXSpwoMrjwpyvdA$>