KCP: Disable tti restriction

[patterniha]

Now, kcp is used for XDNS, so like mtu, the restriction on tti should also be removed.

This is because when we use recursive-resolver, the tti may increase.

i test for some random recursive resolver and it takes 400-600 ms to receive answer from my server, so tti should be set to 200-300.

[patterniha]

@RPRX
First, I mistakenly push to main branch without confirmation, and then revert it immediately, please remove those commits.

[Fangliding]

为什么你会觉得最佳tti是rtt的一半？
还有kcp原定义的interval限制是10~5000ms 我觉得改成这样最好

[patterniha]

Xray-core/transport/internet/kcp/config.go

Line 57 in 9514e98

size := c.GetUplinkCapacityValue() * 1024 * 1024 / c.GetMTUValue() / (1000 / c.GetTTIValue())

for recursive-resolver, certainly, the time it takes for the query to reach server is longer than the time it takes for the response to reach client.

I don't read the the algorithm exactly, but logically tti should be as accurate as possible, to make the speed closer to what the user has set.

Anyway, 100 is too low and needs to be increased.

[Fangliding]

但是最后这个值还要被直接乘20...

[patterniha]

But this final value still needs to be multiplied by 20...

?

///

Also, i set MTU=100, for both side, but i sniff some occasional packets (from both direction) with up to 529 bytes udp-payload!

Approximately 1% of packets exceed MTU, I haven't read the algorithm why these packets are generated, but this problem definitely needs to be fixed because it disrupts the functionality of XDNS.

@LjhAUMEM

[Fangliding]

这里最后算出来的值是对于每次 flush tti 越低 flush 越频繁 所以它计算出的值才和tti负相关

[Fangliding]

But this final value still needs to be multiplied by 20...

?

Xray-core/transport/internet/kcp/sending.go

Line 324 in 9514e98

cwnd *= 20 // magic

Approximately 1% of packets exceed MTU, I haven't read the algorithm why these packets are generated, but this problem definitely needs to be fixed because it disrupts the functionality of XDNS.

#5657 (comment)

哎现在的人

[patterniha]

‍I was only able to connect with decent speed today, and that was with a tunnel that uses white-spoofed-ip to exchange data.
After some effort, my friends were able to get the two spoofable server (outside and inside).

So I couldn't read the messages at all :)

[LjhAUMEM]

Also, i set MTU=100, for both side, but i sniff some occasional packets (from both direction) with up to 529 bytes udp-payload!

For the server side, you can set a larger value, with a maximum of around 972, but generally it's recommended to keep it below 900.

Approximately 1% of packets exceed MTU, I haven't read the algorithm why these packets are generated, but this problem definitely needs to be fixed because it disrupts the functionality of XDNS.

@LjhAUMEM

Yes, it's a known issue and should have been fixed in #5657.

[patterniha]

Also the name "mtu" is misleading, "mtu" is used for ip-header+udp/tcp-header+payload size, and in tun, the name "mtu" is chosen correctly, but here it is used for maximum udp-payload size.

@Fangliding please update the doc and mention this, but i think it is better to rename it to "applicationMTU" or "maxPayload"

[Fangliding]

mtu的确是误导命名 一般它特指链路层最大载荷
不过目前这块文档处于很糟糕的状态 比如预计要减去 udp mask 造成的头部开销（还没做）但是有的mask又不好说（xicmp) 我倾向于等这部分稳定了再更新