Hi, I'm looking at some of the sharkfest sessions on Youtube. For the sessions presented by Hansang Bae, I noticed an interesting topic which is about "Odd Numbers are Evil". I don't really understand what does it mean,guess the expert here do understand what I mean here. So, could you please explain what does this kind of issue mean? Is there any document, video that can be referred to? thanks a lot! asked 31 Dec '13, 00:08  SteveZhou edited 31 Dec '13, 00:09 |
One Answer:
"Odd numbers are evil" refers to the behavior of most TCP stacks to acknowledge each other packet, which means that ACK packets are sent after receiving two data segments. When there is an odd total number of segments in a transmission the last segment has no following segment that gets acknowledged, so the receiver waits and waits and waits, but nothing is received. Finally, a so called "delayed ACK" is sent, but that takes a few hundred milliseconds. This kind of delay can also lead to more problems, one of which Hansang explained in a post in the official Wireshark blog when the Nagle algorithm kicks in and creating more problems. answered 01 Jan '14, 17:02  Jasper ♦♦ |
fantastic!!! This is really what I want. I do observed some traces likes this:
A to B file transfer:
.... several ms,packet 1 (A->B) several ms,packet 2 (A->B) several ms,packet 3 (A->B) several ms,packet 4 (A->B) several ms,packet 5 (A->B) several ms,packet 6 (A->B) several ms,packet 7 (A->B) tens ms, packet 8 (A<-B) <-- Ack for packet 7 ....
There are 7 packets out from A to B, which is odd number. Then the Ack (packet 8) took tens of ms to acknowledge back.
One more question, you just said there should be an ACK for every two packets, why did I see only one Ack which acking all of the 7 packets? Is it a just a different implementation of TCP delay-ed Ack?
That would be a little uncommon, because most stacks do in fact ACK every second packet. But there is no rule that doesn't allow for a host to acknowledge a whole bunch of packets in one ACK packets, so it is possible. Something like that is often seen when packet loss occurred and and ACK is sent for all packets that arrived since the gap was detected when the gap is finally closed by a retransmission.
I don't really understand this part of you,
"Something like that is often seen when packet loss occurred and and ACK is sent for all packets that arrived since the gap was detected when the gap is finally closed by a retransmission."
Do you mean out-of-order packet arrival? Could you give me an example?
Out-of-Order is usually not enough to provoke it.
Let's say you have 10 segments sent to the receiver, and the third segment gets lost. The receiver will acknowledge the first two, and acknowledge them again when segment 3 and 4 arrive ("Dup ACK #1"), then again for segments 5 and 6 ("Dup ACK #2") and so so until all 10 segments arrived. When the sender resends the missing segment (making the series of segments complete at the receiver) it will (in most cases) acknowledge all 10 segments in one ACK, and not send 4 ACKs. This is what I meant.
I think when the 3rd segment gets lost, all the arrivals of the left 7 segments (#4,#5,#6,#7,#8,#9,#10) will each cause a Dup ACK to the sender. Most probably this will trigger a Fast Retransmission to fix the gap of segment 3. When the missing segment (#3) arrive, the receiver will Ack all of the bytes till #10. I think this is what you mean here.
In my trace, there is no retransmission actually. So it way be a tcp stack implementation difference.