Re: [L4s-discuss] [EXTERNAL] Accurate ECN & TCP_CONGESTION & connect()

[Neal Cardwell <[e-mail]>]

Hi Bob,

You should be able to enable use of Accurate ECN, regardless of the current
congestion control algorithm, using:
  sysctl net.ipv4.tcp_ecn=3

That should cause new connections to negotiate (in the SYN/SYN-ACK
handshake) Accurate ECN, whether the CC is prague, cubic, bbr, etc. Then
when you use TCP_CONGESTION after connection establishment you should be
able to select prague as the connection's CC even if the connection was
started with cubic CC.

See:
https://github.com/L4STeam/linux/blob/testing/Documentation/networking/ip-sysctl.rst
tcp_ecn - INTEGER

Control use of Explicit Congestion Notification (ECN) by TCP. ECN is used
only when both ends of the TCP connection indicate support for it. This
feature is useful in avoiding losses due to congestion by allowing
supporting routers to signal congestion before having to drop packets. A
host that supports ECN both sends ECN at the IP layer and feeds back ECN at
the TCP layer. The highest variant of ECN feedback that both peers support
is chosen by the ECN negotiation (Accurate ECN, ECN, or no ECN).

The highest negotiated variant for incoming connection requests and the
highest variant requested by outgoing connection attempts:
ValueIncoming connectionsOutgoing connections
0 No ECN No ECN
1 ECN ECN
2 ECN No ECN
3 AccECN AccECN
4 AccECN ECN
5 AccECN No ECN

Default: 2


best regards,
neal


On Fri, Jan 5, 2024 at 3:20 PM rjmcmahon <rjmcmahon=
[e-mail]> wrote:

> On 2024-01-05 06:45, Overcash, Michael (CCI-Atlanta) wrote:
> > The ECR bits are part of the IP header and are not concerned with the
> > TCP 3-way handshake. This is also why UDP protocols can utilize L4S.
> >
> > If L4S is enabled after the TCP session is established, then the TCP
> > handshake packets will end up in the Classic Queue but subsequent
> > packets will go to the AQM queue.
> >
> What about accurate ECN? I assume this can only be enabled per the 3WHS.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn
>
> During the TCP handshake at the start of a connection, to request more
> accurate ECN feedback the TCP Client (host A) MUST set the TCP flags
> (AE,CWR,ECE) = (1,1,1) in the initial SYN segment.
>
> If a TCP Server (B) that is AccECN-enabled receives a SYN with the above
> three flags set, it MUST set both its half connections into AccECN mode.
> Then it MUST set the AE, CWR and ECE TCP flags on the SYN/ACK to the
> combination in the top block of Table 2 that feeds back the IP-ECN field
> that arrived on the SYN. This applies whether or not the Server itself
> supports setting the IP-ECN field on a SYN or SYN/ACK (see Section 2.5
> for rationale).
>
> When the TCP Server returns any of the 4 combinations in the top block
> of Table 2, it confirms that it supports AccECN. The TCP Server MUST NOT
> set one of these 4 combination of flags on the SYN/ACK unless the
> preceding SYN requested support for AccECN as above.
>
> Once a TCP Client (A) has sent the above SYN to declare that it supports
> AccECN, and once it has received the above SYN/ACK segment that confirms
> that the TCP Server supports AccECN, the TCP Client MUST set both its
> half connections into AccECN mode. The TCP Client MUST NOT enter AccECN
> mode (or any feedback mode) before it has received the first SYN/ACK.
>
> Bob
>
> --
> L4s-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/l4s-discuss
>