L4STeam / linux

Kernel tree containing patches for TCP Prague and the dualpi2 qdisc
Other
47 stars 16 forks source link

sysctl net.ipv4.tcp_ecn=0/1/2/3 TCP prague server using "testing" branch all shows ECT(1) #13

Closed Xingyuxingyu closed 1 year ago

Xingyuxingyu commented 1 year ago

There seems to be a bug in the L4S kernel "testing" branch where when the server is configured with sysctl net.ipv4.tcp_ecn=0/1/2/3, a TCP flow using prague all shows ECT(1) in wireshark.

How to set the ECT(0) and Not-ECT in prague?

Of course, in bbr2 or cubic, there are no problem, sysctl net.ipv4.tcp_ecn=0 means Not-ECT, sysctl net.ipv4.tcp_ecn=1 means ECT(0), sysctl net.ipv4.tcp_ecn=2 means Not-ECT( in this case, is there any problem?), sysctl net.ipv4.tcp_ecn=3 means ECT(1)

koen0607 commented 1 year ago

Prague will force the use of accurate ECN independent on the sysctl net.ipv4.tcp_ecn setting, and if the other end is supporting accurate ECN it will use its scalable congestion control, which needs to use ECT(1), so as a consequence, you cannot use the "Prague" CC with ECT(0) (is not allowed by RFC9331). But Prague falls back to a classic CC under some conditions, so it might use non-ECT or ECT(0), only in that case.

Setting ECT(1) is only controlled within the CC module and only scalable CCs should use ECT(1) by setting the TCP_ECN_ECT_1 flag in ecn_flags during init, and not to forget to clear it during release.

Note that setting sysctl net.ipv4.tcp_ecn never will control the use of ECT(0) or (1) in Prague. Setting this parameter to 3 only enables accurate ECN, which supports both ECT(0) and ECT(1), depending on the congestion control that is used (non-scalable or scalable).

Probably similar behavior will be used for BBR and other scalable congestion controls that are intended to run on the Internet. Currently in BBRv2, the ECT(1) use is coupled with tcp_ecn=3, which is causing the confusion. The BBR congestion control doesn't support the Classic ECN response, so according to RFC9331 it should never use ECT(0) on the Internet (making its setting tcp_ecn=1 and 2 invalid options for the Internet. DCTCP is altogether unsafe to use on the Internet, as it is not RTT independent, not pacing well enough and is too bursty. All these Prague requirements of RFC9331 are fixed in TCP_Prague.

Hope this clarifies and currently the only way to enable in Prague non-ECT or ECT(0) is by controlling the other end's ECN/acc-ECN mode. If you want to force the classic behavior of Prague at one end only, then just set Reno or Cubic congestion controls with or without ECT(0)...

I'll close this issue, unless you still see problems according to the above intended behavior. In that case please make a new issue. I'll open a new issue for BBR, to fix its ECT(0)/(1) issues.

Xingyuxingyu commented 1 year ago

这是来自QQ邮箱的假期自动回复邮件。您好,已收到您的邮件。我会尽快给您回复。