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
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

Cheers


Bob

> Regards,
>
> Carl Klatsky
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

_______________________________________________
tcpm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpm