Good day. I sniffered just a regular ftp download and noticed that ACK from client are sent every 2KB received:
I checked receive window size from client (window size in ACK message)and it size is 65536
So far I know theory of TCP window size determine the amount of data that can be sent before ACK but here I observe very different behavior. Can somebody make it clear - what rule used here to send ACK packets? asked 27 May '15, 05:22  mongolio edited 27 May '15, 20:15 |
One Answer:
The TCP window size is the amount of data can be sent before an ACK is required. It doesn't mean that the receiver has to wait that long before acknowledging. The normal rule is to acknowledge every other packet, so you get an ACK after two packets. The reason is that it is better to ACK in a constant way to keep the flow going, because if you ACK only when the window size is reached you have to wait one full roundtrip time before you can continue to send. ACKs that come in while sending move the window forward and allow the sender to continue without every having to wait. answered 27 May '15, 06:04  Jasper ♦♦ showing 5 of 9 show 4 more comments |
And what in case if one packet will be lost on the way from server to client? Server will stop receiving ACK, but will keep sending packets till window size reached and only after that will start retransmission of all segments he sent till previous ACK?
if a packet is lost the receiver will continue to ack every second packet, but the ACK number will be the one just before the gap. Those ACKs are marked by Wireshark as "Duplicate ACK". They signal packet loss.
Depending on the TCP stack of the sender it will then trigger the retransmission sooner or later; one of the mechanisms is the "Fast Retransmission" which is performed after receiving two or three duplicate ACKs (which is why we call the trigger "triple duplicate ACK"). Alternatively you may see a Retransmission using SACK (Selective Acknowledgements), which pinpoint the missing segments by specifying the sequence number edges of the gap.
So no, modern TCP stacks don't keep sending until the Window is full; they'll try to recover from packet loss as early as possible to avoid long delays until the retransmission fills the gap.
Tnx for great clarifications! BTW one more question - so there is no any sense in having big window size with modern applications and TCP window scale option is rudiment?
Window size is important, depending on bandwidth and round trip time. The higher the bandwidth and the higher the RTT the higher the window size must be. This has nothing to do with modern applications. In LAN networks small window sizes are sufficient; on WAN links you need large window sizes.
Jasper, two more question here 1) is not window already full when sender receives first Duplicate ACK? As I understand if it received Duplicate ACK than RTT already passed from moment unacknowledged segment was send and during RTT sender must already transmit data amount equal to receive window size.
2) Am I understand correctly that with Fast Retransmission time required to resend lost segment can be only slightly better than with Adaptive retransmission timer, cos RTT will be passed anyway by the time of raction in both cases?
1) no, only sometimes. A Duplicate ACK is sent when the receiver detects packet loss, meaning, when it receives a sequence number that is higher than expected. Window full happens occasionally when the advertised window size wasn't large enough to keep sending packets when that happened.
2) that depends on how good the timer is - reacting to two Duplicate ACKs is pretty consistent, and can only be beat by SACK edges. Timers are always prone to errors, e.g. retransmitting too soon (resulting in a "Spurious Retransmission") or retransmitting too late (resulting in a slow connection)
Jasper, thanks a lot for your patience and willing in helping me to get grasp of some basic principles of TCP!
1) Can you please point me where i am wrong in my understanding: Receive window size is an amount of data that a sender can transfer to a receiver during one RTT period (this comes from BDP formula). So when the sender receives Duplicate ACK signaling about packet lost, RTT from the moment the lost packet was sent has already passed, and if the sender use packet size equal to MSS during transmission than amount of data equal to a window size must already be in the sender buffer.
2) > that depends on how good the timer is So far I have heard only about Adaptive TCP retransmission algorithm used to calculate out smooth time to wait until start retransmission of the segment where TCP Timeout=SRTT+4*Svar. Are there another algorithm used in modern TCP stack implementations?
1) true, but only on paper. In reality, modern TCP stacks don't stop at the BDP window size; instead they keep increasing it for a while to allow more than what fits into an RTT period. Otherwise a single lost packet may slow everything down because of what you said.
2) yes, you still sometimes see a fixed 3 seconds delay on the evil odd packet, meaning, if you have a connection where the last packet is an odd number (meaning nothing follows it to trigger the ACK) you may run into this. It's not that common these days anymore though.
Many thanks for clarifications!