> But why bother with UDP? Why can’t you do this with a TCP connection? Just measure the time deltas and throttle yourself if it spikes, right? Good question, a

> But why bother with UDP? Why can’t you do this with a TCP connection? Just measure the time deltas and throttle yourself if it spikes, right? Good question, and I don’t have a good answer. Perhaps one of you can give a persuasive one, lest you agree that ISPs should just throttle UDP by design. The issue is microsoft windows. It doesn't have pluggable congestion controllers. On linux you could insmod a ledbat.ko and have userspace applications choose that as congestion controller for their TCP connections. Another reason for uTP is that nat traversal is easier with UDP than it is with TCP. Especially if the NAT gateways use endpoint-idependent mappings for UDP but address-dependent mappings for TCP. But that's more an argument for IPv6 than for UDP. > One idea that comes to mind is that the goal is to throttle sends and receives. You control your sends, but you’re at the mercy of the counterparty for receives. You’d need to keep throttle info for every peer, and notice when their pings spike, not just yours. Then you’d send fewer packets. But that’s what uTP does, and that doesn’t answer “Why do it in UDP instead of TCP?” You can do this in bittorrent actually by throttling your request messages. But request pacing is tricky because userspace applications will have a difficult time estimating the receive-bottleneck-buffering across multiple TCP streams. Though maybe it could be done on linux via socket timestamping, I haven't looked into that. BiglyBT implements a crude version of request throttling, but it's not adaptive, you have to set a download rate limit. But when it does kick in it manages to converge its requests on a few high-bandwidth/low-latency peers which should result in less long-distance traffic and shallower queues.