setting different dataShard/parityShard on client and server

[ghost]

Currently, kcptun requires dataShard/parityShard to be the same on client and server.

I want to disable FEC only on the transmitted packet from client to server, and keep the FEC on the other direction, as there is 0% packet loss on the up link and 50% loss on the down link.

I tired setting different values to server and client, and they seem to talk to each other for a second, then the connection died.

It seems that the kcp-go protocol sends the dataShard/parityShard with every packet. I would like to know if there is any particular reason why FEC are required on both links, and if there is a way to disable one of them.

[koolca]

期待能分别指定client/server端的upload/download 的ds/ps，支持只开server2client的FEC，能单独关闭client2server的FEC

[xtaci]

it's difficult to seperate, the reason is because kcptun has no handshake procedure.
then, there's no way to exchange parameters.

---

BUT, there may be some possiblility to deduct parameters from previous received packets.

[xtaci]

the main concern for adding 'remote data shard' or 'parity data shard' parameters is compatibility issue.

[koolca]

我理解的是，client或server端只是在FEC解码和编码使用了不同的ds/ps参数，例如client的编码与server的解码一套参数，client的解码与server的编码一套参数。
我不懂网络编程，如有错误请见谅。

[ghost]

the main concern for adding 'remote data shard' or 'parity data shard' parameters is compatibility issue.

Just wanted to ask if user can configure ds/ps for both uplink and downlink on both server and clients.
There will be 4 numbers in total, which is shared by client and server.
Maybe the uplink ds/ps can be set to downlink as default.

There shouldn't be any protocol modification, or I missed something?

[xtaci]

yes <ds, ps, rds, rps> , four parameters to set FEC, and we need to handle config file compabitility issue for routers etc...

[xtaci]

only API extension, no protocol modification.

[xtaci]

I mean, the BEST way to handle this is some kind of auto-tunning FEC parameters algorithm regarding incoming packets sequence from the other peer. If this can be done in this way , then we don't need to add 2 extra parameters.

[ghost]

Auto-tunning FEC is exactly what I am trying at the moment. I wrote some scripts to send UDP packets for measuring bi-directional losses on both uplink and downlink, and I sent those information via a TCP connection over smux to the other end and restarts the server and client.

This dirty hack kind of works, but the problem is that if the client accidentally restarts, it will try to use a wrong FEC setting to connect to the server. Also, the server takes the same FEC param for all incoming clients, which is not an ideal solution if the network condition of the client varies.

[ghost]

In UDPspeeder the FEC configuration is written in every UDP packet, and different groups of packets can have different ds/ps. This makes auto-tuning FEC a lot easier, but it will send a lot of redundant information as the tuning shouldn't be performed very frequently.

[xtaci]

https://github.com/xtaci/kcp-go/tree/autotune
can you review the commits of this branch ?

[xtaci]

https://github.com/xtaci/kcptun/releases/tag/v20201010

[keeno1982]

借问一下，20201010这个版本意思是可以不用配置服务端和客户端的dataShard，parityShard这两个参数了吗？程序会自己动态调整？

[xtaci]

不是，是两头可以设置不同参数，但确实为自动调整铺平了道路。

[keeno1982]

期待有自动调整的版本，这两个数值的设置太复杂了，国际线路环境一直在变化，用哪组值都觉得不够好

[wangyu-]

yes <ds, ps, rds, rps> , four parameters to set FEC, and we need to handle config file compabitility issue for routers etc...

In UDPspeeder there is no rds and rps, the receiving-end is just a decoder that decodes anything the sending-end sends, the receiving-end doesn't know any info of sending-end in advance. To achieve this, <ds,ps,idx> is written in every packet, for example <10,5,3> means for this FEC group we have 10 original packets with 5 redundant packets, and the current packet is the 3-rd packet in the group.

In addition, there is a group ID to help identify which FEC group the packet belongs to when out of order delivery happens. Finally it becomes like <group_id,ds,ps,idx>