xtaci / kcptun

A Quantum-Safe Secure Tunnel based on QPP, KCP, FEC, and N:M multiplexing.
MIT License
13.86k stars 2.54k forks source link

manual mode -nc 0 stuck in low speed forever #906

Open rwasef1830 opened 1 year ago

rwasef1830 commented 1 year ago

Hello,

client config:

-mode=manual -interval 10 -datashard 10 -parityshard 3 -nodelay 1 -resend 2 -nc 0 \
    -rcvwnd 4096  -sndwnd 4096 -conn 25 -l "127.0.0.1:%SS_LOCAL_PORT%" \
    -r "%SS_REMOTE_HOST%:%SS_REMOTE_PORT%" -nocomp -crypt salsa20 -key "key"

server config:

{
        "listen": ":41444",
        "target": "localhost:22112",
        "mode": "manual",
        "crypt": "salsa20",
        "key": "key",
        "nocomp": true,
        "sndwnd": 4096,
        "rcvwnd": 4096,
        "interval": 10,
        "datashard": 10,
        "parityshard": 3,
        "nodelay": 1,
        "resend": 2,
        "nc": 0
}

WIth nc = 1, the server floods my internet connection with UDP packets and causes all other apps and PCs on LAN to experience packet loss. Since congestion control is off, there's no way to tell the sender to "slow down" by router QoS packet dropping.

So I set nc = 0 on client and server, but in this case the download throughput remains locked at 70 kilobytes per second never increasing. If I turn off nodelay on client and server also, I get better speed of a few hundred kilobytes per second, but it's still very slow. I tried changing sndwnd/rcvwnd, interval, datashard and parityshard and resend with no result.

There is no documentation on how to make nc = 0 (congestion control active) working correctly. Is there something wrong in my usage ? From what I read on kcp project, I see that it's supposed to behave as TCP slow start/ramp up, but it's not working for my case.

Thanks.

xtaci commented 1 year ago

decrease the sndwnd & rcvwnd, you can start from 256

rwasef1830 commented 1 year ago

I tried, it didn't help. It just made the low speed starting level lower. When I tried changing the sendwnd / rcvwnd to different values. It seems that larger values make the starting speed faster but then it either never enlarges the window or actually decreases it (it slows down). Maybe this is related to RTT ? My RTT to my VPS is around 80ms and I'm testing a normal https download from a server near to my VPS (~82ms).

rwasef1830 commented 1 year ago

OK here's an interesting thing, iperf3 forced through ss + kcp behaves seemingly correctly, but a normal http download through ss + kcp does not. I will investigate more.

I was wrong I was accidentally testing without kcptun, it's still not working. Even iperf has the same issue. I think there's an issue in the window enlargement / scaling algo of kcp. It's interesting to note that when I set my VPS tcp congestion algorithm to conservative algo like reno or vegas, it has the same issue, rarely increases speed. I think kcp needs to implement bbr algorithm or similar.