Nagle's algorithm and uTP

[thrnz]

I've noticed that the way libtorrent handles undersized uTP packets is different than that of libutp and the original RFC introducing Nagle's algorithm, and introduces a potential delay of up to an RTT.

If I'm reading the code correctly, currently libtorrent holds back sending an undersized uTP packet until its either no longer undersized, or until there are no more unack'd packets in flight. As a result, the packet can be held back for up to an entire RTT waiting for acks to arrive before being transmitted.

https://github.com/arvidn/libtorrent/blob/084219e75175b4f3ab096aed83f32d70ef1f2ee4/src/utp_stream.cpp#L1514-L1520

libutp appears to only hold back an undersized packet until the next ack is received. The RFC also only mentions holding back the packet until something arrives from the other end (though it is from 1984, and I don't know if things have changed). As a result, there is much less likely to be any significant extra delay.

I'm not sure what the effects of this extra delay might be - if any - or whether it's been intentionally done that way or was an oversight. One thing that does come to mind though is when a peer is choked, where there will be a large stream of outgoing data that ends in a tiny choke message. The choke message could potentially be held back as undersized until everything previously in-flight is ack'd, causing the peer to continue requesting new pieces, and - if the extra RTT delay on top of the existing send buffers and underlying latency is high enough - potentially be disconnected due to sending requests while choked.

I'd be surprised if this alone has any meaningful effect on #3542.