On Mon, May 10, 1999 at 07:16:34AM +0200, David S. Miller wrote:
>
> 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.
I agree with that, but a few comments:
- it doesn't handle the case properly when the new pmtu is < 0.5*old_pmtu,
in this case it still eats a time out because it doesn't retry until
all tcp_fragment()s have finished their job.
- in some cases it can cause quite some packet flood. the new code is
even more aggressive than the old one or fast retransmit. would it make sense
to restrict it to only kick a few packets?
-Andi
--
This is like TV. I don't like TV.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
