Interesting discussion how Nagleing (goal is to avoid sending "tinygrams" to the peer, implemented by filling the sender buffer (delaying the "send") till an ack of a previous send is received) - and delayed ACKs (on the receiver side, do not immediately send an ACK, but delay it, so that the ack can be piggybacked on something the receiver app wants to send) can cause TCP performance problems. See this and this.
Note of course, how the tinygram issue is different from the Silly Window issue (tinygram - TCP window (as advertised by the peer) is almost empty and silly-window (TCP window is almost full).
Of course, no big deal in retrospect ... but interesting i thought...
(Another interesting thing to note is that the so-called "congestion window" is a way where the sender does not fill up the whole receiver's advertised window at once, but fills it up slowly (the so called cwnd growth function))
(Another interesting thing to note is that the so-called "congestion window" is a way where the sender does not fill up the whole receiver's advertised window at once, but fills it up slowly (the so called cwnd growth function))
Good read.
ReplyDeleteThanks
Problems:
ReplyDelete1. TCP throughput is roughly proportional to 1/sqrt(RTT). So more the RTT (round trip time) the worse the performance. This goes against the principle of buffering.
2. If we do a distribution of packet sizes in the Internet (refer http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5199061&tag=1) we see the distribution to be bimodular, 1500 bytes and 95 bytes peak. So unless u r doing telnet, you wont use Nagle.
Ajay