On Wed, 17 Jan 2001, mukesh agrawal wrote:
>
> From looking over the code, running some experiments, and from the mailing
> list archive, it looks like packets simply get dropped inside the kernel
> when the queues overflow.
>
> This seems to interact badly with TCP. If the initial retransmit time out
> is 3 seconds, and one of the first few packets gets dropped (before the
> rtt estimate is updated), then the connection is stalled for 3 seconds.
> (TCP packet gets dropped silently, then kernel waits an RTT for a response
> before retransmitting.)
>
> Two questions:
>
> 1. Can this really happen, or have I overlooked something? (Our
> experiments suggest that it can happen.)
>
In OOM conditions, the drop will happen much earlier in the packet
processing probably at the driver level, not the way you described it i.e
at the socket queueing time.
One thing that will NEVER happen: remote end receives an ACK for a packet
that is then dropped in the kernel.
If it gets dropped before being processed then it's a c'est la vie.
I dont know how any other OS can solve this without (as Alexey nicely put
it) infinite memory. TCP is, by design, resilient to this.
cheers,
jamal
> 2. If this can happen, is it worth changing? In particular, we might not
> want to wait the entire RTT before retransmitting the packet if it was
> dropped inside the kernel.
>
|