Request for TCP socket option TCP_NOTSENT_LOWAT

[galaxyport]

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I provided the complete config and logs, rather than just providing the truncated parts based on my own judgment.
• I searched issues and did not find any similar issues.

Version

latest

Description

Based on the article written at https://blog.cloudflare.com/http-2-prioritization-with-nginx, this TCP option on the server can reduce bufferbloat in HTTP/2 and gRPC, enabling a more responsive connection. However, when this option is enabled on the server, it only affects the user's downlink.

By adding this socket option to Xray, we can also benefit from its advantages on the uplink side.

Reproduction Method

REQUEST OPTION

Client config

Details

Server config

Details

Client log

Details

Server log

Details

[Fangliding]

Even if we add it, it can only work on Linux client.
If you are using Linux you can use sysctl to change it.
Btw, change it has no help to xray(xray has no such "critical resource", all data are the same)

[mmmray]

TIL

however, it seems chromium may not set this even on linux: https://source.chromium.org/search?q=NOTSENT_LOWAT&sq=&ss=chromium

theoretically, splithttp has many small "resources" (POST requests) during upload (so, related to client's send buffer), but I assume they are already prioritized correctly.

[galaxyport]

Currently, adding this option to Android is not possible because it requires root system access. However, if it is added, it will be possible to use it on Android without root.

The term "critical resource" is used in relation to HTTP/2, whereas this option operates on TCP.

I was thinking that this option can be effective in preventing bufferbloat if there is a bandwidth limitation on the outgoing side. In such a case, in multiplexed connections like h2 and gRPC, the sending buffer can be kept small so that a large portion of the data doesn't sit in the operating system's buffer. When the upload bandwidth is low, if a large amount of data is buffered on TCP, it causes head-of-line blocking for each connection within the multiplex. The connections in the multiplex will wait until the previous request is sent before they can be sent. With the addition of this option, the connections will be used more fairly, reducing latency.

[Fangliding]

Actually, setting sockopt on Android is not always effective(
The key is not multiplexing, but TCP buffer affects HTTP2's resource prioritization, resulting in delayed loading of critical resources and slow down the loading speed of the entire webpage. It is obvious that xray does not have such a thing.
Putting aside theory, at least provide test results that this sockopt can increase speed, otherwise this will not be planned

[mmmray]

The connections in the multiplex will wait until the previous request is sent before they can be sent. With the addition of this option, the connections will be used more fairly, reducing latency.

My understanding is that this option is set by cloudflare because the priorities per multiplexed stream are constantly changing within the server, as the HTML response is streamed and new <script src=...> tags (or whatever) are discovered. If a too large send buffer is inbetween, the server cannot react to those priority changes quickly. This is not a situation xray deals with at all, it doesn't really do QoS between streams to begin with (in that context: what even is this fairness you speak of?)

perhaps xray can allow for setting sockopt based on c_int (like "rawTcpOptions": {"25": ...} where 25 is the value for the constant TCP_NOTSENT_LOWAT) -- this is pretty gross but it would preempt such discussions entirely

[Fangliding]

In the end, we still supported this. You can test whether it will bring performance improvement ((

[mmmray]

nice work, thanks fangliding

[galaxyport]

In the end, we still supported this. You can test whether it will bring performance improvement ((

thank you, theoretically it shouldn't bring speed gains, actually it can cut a little bit of that performance in favor of responsiveness and latency in bloated connections specifically variable speed links, for example when we have low upload speed and variable upload speed on mobile data.

[BK8000L]

You can test whether it will bring performance improvement

link speed is 10mbit/s

vless+mux1024+lowat=4294967295 (linux default)

vless+mux1024+lowat=16384 (like on cloudflare)

vless+mux1024+cloudflare+lowat=4294967295 (linux default)

vless+mux1024+cloudflare+lowat=16384 (like on cloudflare)

lowat was changed on both sides