From: Andi Kleen <[EMAIL PROTECTED]>
Date: 09 May 1999 15:39:05 +0200
I cannot understand how this could make a
difference. tcp_simple_retransmit() is only a optimization to
resend the packet quickly without waiting for the timeout. But it
doesn't remove packets from the write queue, thus if it fails for
some reason the retransmit timer should resend them always.
I completely agree. But can we both agree that the code was wrong
there, and needed to be fixed? I sent the change out for testing
because I wanted to confirm what you are saying, that somehow the
retransmit queue is being setup wrongly in these cases.
The code, as it was, would behave quite stupidly. Consider we had two
oversized packets in flight which exceeded the path MTU, the old code
would subsequently:
sender --> receiver first PMTU-size bytes of packet1
sender --> receiver first PMTU size bytes of packet2
We would still then eat some kind of timeout, or at best utilize fast
retransmit when we get the ACK for the second resent packet _iff_ we
had other smaller subsequent packets in flight to keep the ACK
feedback going.
The new code corrects this by making sure we resend all the data that
was lost, not just the initial PMTU-sized chunks we create.
Furthermore, it should in fact do so efficiently since via fragmenting
and re-coalescing the packets re-sent should be of the largest size
feasible with the given state of the write queue.
Again, do we agree on this? The fix is necessary, independant of
whether it fixes the bug which started this thread.
When the retransmit timer doesn't send the second fragment it means
it isn't properly inserted into the list.
Again, we agree. This is what made me look at this code in the first
place, and fix this other problem.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
