![]() This can be inferred by the SACKs #36 and #37 followed by ACK #38, all in the space of 2 microseconds. Packet #30 is seen in the correct order in the capture - but is overtaken before it arrives at the receiver. This behaviour is not in the "fast" capture. In the "slow" example, we see one of those OOO cases very early, during the third burst in the slow start phase when we've only ramped up to 7KB per RT. Note the vertical height of the bursts per RTT. You could calculate 64KB per RTT vs 8KB per RTT (RTT=22ms) - or just say that "fast" has 8 times the throughput of "slow".Ĭompare these snippets of Stream-TCP-Trace graphs - which are essentially the same for the whole periods. ![]() "Fast" maintains a consistent packets-in-flight of 64KB whereas "slow" maintains just 8KB. The difference in throughputs is due to the different send buffer sizes. These OOOs and retransmissions have very little or no effect on the overall throughput. Data in #33247 is overtaken, SACKs #33321, #33322, #33323 announce it, ACK #33324 acknowledges the missing 1460 but client data #33325 is sent as an unnecessary retransmission. That is not enough to stop the client sending #47617, a retransmission of the 1460 bytes, in response to the 3 x SACKs (equals 3 x Dup-ACKs). One RTT later, SACKs #47613, #47614, #47615 announce a gap of 1460 then ACK #47616 (zero time after #47615) tells us that the 1460 byes arrived after all. "Slow": The first 1460 bytes of #47602 are overtaken downstream. I'll just give one example from each capture: We can infer this by SACKs that originate from the receiver. The amount of time they are OOO is just 1 microsecond. There are several instances of packets arriving out-of-order at the receiver (but in the correct order when we see them). The minimum RTT is the same in both cases at just under 22ms (the "fast" example is a touch longer than the "slow"). The 64KB is reached by ACK #101 in "fast" and ACK #103 in "slow". The server advertises a receive window of 64KB constantly in both cases (after a ramp-up very early on that closely matches the slow start). Both support SACKs and both specify an MSS=1460. Therefore, the receive window can never be more than 64KB. First some items that are the same (or close) in both captures:ģ-way handshakes are the same, client supports windows scaling but server does not (or something in the middle doesn't).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |