I'm reading about TCP data flow, Delayed ACK and Nagle's Algorithm.
So far I understand that:
- The Delayed ACK implementation on TCP creates a delay on the acknowledgement of segments received to give the opportunity for the application to write some data along with the acknowledgement, thus avoiding sending an empty ACK packet and contributing to network congestion.
- The Nagle's Algorithm implementation states that you can't send a small TCP segment while another small segment is still not acknowledged. This avoids the traffic being loaded with several tinygrams.
On some interactive applications, like Rlogin for instance, Nagle's Algorithm and Delayed ACKs can "conflict":
Rlogin sends the keyboard input to the server as we type them and some keys (like F1) generates more than one byte (F1 = Escape + left bracket + M). Those bytes can be sent in different segments if they are delivered to TCP one by one.
The server doesn't reply with an echo until it has the whole sequence, so all the ACKs would be delayed (expecting some data from the application). The client on the other hand, would wait for the first byte acknowledgement before sending the next one (respecting the Nagle's Algorithm). This combination ends up resulting in a "laggy" Rlogin.
tcpdump of the F1 and F2 key being sent on a Rlogin is represented below:
type Fl key 1 0.0 slip.1023 > vangogh. login: P 1:2(1) ack 2 2 0.250520 (0.2505) vangogh.login > slip.1023: P 2:4(2) ack 2 3 0.251709 (0.0012) slip.1023 > vangogh.login: P 2:4(2) ack 4 4 0.490344 (0.2386) vangogh.login > slip.1023: P 4:6(2) ack 4 5 0.588694 (0.0984) slip.1023 > vangogh.login: . ack 6 type F2 key 6 2.836830 (2.2481) slip.1023 > vangogh.login: P 4:5(1) ack 6 7 3.132388 (0.2956) vangogh.login > slip.1023: P 6:8(2) ack 5 8 3.133573 (0.0012) slip.1023 > vangogh.login: P 5:7(2) ack 8 9 3.370346 (0.2368) vangogh.login > slip.1023: P 8:10(2) ack 7 10 3.388692 (0.0183) slip.1023 > vangogh.login: . ack 10
Now the doubt: Even though the page I read states that the server doesn't reply with an echo before it has the whole key sequence, the packets captured through
tcpdump shows that the keys are being echoed on their respective ACKs (the first reply is 2 bytes long because the echo from ESC is two characters - caret + left bracket).
If data is being sent from the application to TCP (the echo response) why are the ACKs being delayed? According to what was stated, about the server waiting the full sequence before echoing it, wasn't the ACKs supposed to contain no echo up to the last ACK, that would contain the whole sequence echo?