3 ms·

Thanks, I spent some time trying to figure out how I could configure this retransmission timeout. The SACK solution you describe sounds like a great idea. Is t

by ehsanu1 14y ago

Thanks, I spent some time trying to figure out how I could configure this retransmission timeout. The SACK solution you describe sounds like a great idea. Is that the optimum solution though? Could one, say, have two TCP connections and send the same data on both? This way, maybe when one connection experiences packet loss, the other can carry on. This probably doesn't actually work due to high packet loss correlation or something (I have no idea about networking), so it would be interesting to hear what experts think. Are there any other relevant parameters to tweak in order to make TCP's performance slightly more like that of UDP? Working on an MMO game myself (for fun), so would be great to know.

ajross 14y ago
It's a complex subject, but don't think about it as TCP being "low performance". In fact TCP will vastly outperform basically any hand-written UDP protocol at large sequential transfers over fat networks (or I guess it would be better stated that any hand-cooked protocol that performed as well as TCP would be isomorphic to TCP). The characteristic you want from UDP is out of order sequencing: you want to see the most recent packet as soon as it arrives, even if some got missed before. No version of TCP does that, because TCP is a reliable protocol which presents a stream metaphor. Packet loss will always show up as latency burps, though as I point out generally that burp is one extra RTT.
- ehsanu1 14y ago
  Thanks for the reply. Yeah, I understand TCP enforces packet order and works really well for large transfers etc. But when writing a game where people interact in "real time" through their browser via websockets, anything to get TCP latency down is a plus in my book. While packet loss is bound to cause some latency issues, I just want to minimize the latency hit for packet loss as much as possible. For instance, in a high packet loss situation, to overcome double loss (where a retried packet gets lost, causing 2xRTT of extra latency), perhaps TCP can send multiple retries at once after a single lost packet. For all I know, maybe this is a standard configuration parameter that I just have to set appropriately.

by ehsanu1 14y ago

ajross 14y ago

It's a complex subject, but don't think about it as TCP being "low performance". In fact TCP will vastly outperform basically any hand-written UDP protocol at large sequential transfers over fat networks (or I guess it would be better stated that any hand-cooked protocol that performed as well as TCP would be isomorphic to TCP). The characteristic you want from UDP is out of order sequencing: you want to see the most recent packet as soon as it arrives, even if some got missed before. No version of TCP does that, because TCP is a reliable protocol which presents a stream metaphor. Packet loss will always show up as latency burps, though as I point out generally that burp is one extra RTT.

ehsanu1 14y ago
Thanks for the reply. Yeah, I understand TCP enforces packet order and works really well for large transfers etc. But when writing a game where people interact in "real time" through their browser via websockets, anything to get TCP latency down is a plus in my book. While packet loss is bound to cause some latency issues, I just want to minimize the latency hit for packet loss as much as possible. For instance, in a high packet loss situation, to overcome double loss (where a retried packet gets lost, causing 2xRTT of extra latency), perhaps TCP can send multiple retries at once after a single lost packet. For all I know, maybe this is a standard configuration parameter that I just have to set appropriately.