Andi Kleen wrote:
> On Sat, Sep 01, 2001 at 07:17:29PM +0200, Jamie Lokier wrote:
> > The appended "tcpdump -i ppp0 -n" trace shows an excessive number of
> > retransmits from the remote POP server. The retransmits are triggered
> > by excessive duplicate ACKs from the local client. By excessive, I mean
> > lots of retransmits of the same data.
>
> The duplicate ACKs should not cause any retransmits (unless the sender
> is badly broken), because they contain a high enough ACK number.
We are receiving frames with sequence number <= the ACK we're sending.
When the remote end receives those ACKs, it is seeing a series of
duplicate ACKs for data it sent about 5 frames ago. So of course it
retransmits the data starting from 5 frames ago. As it receives a whole
series of the same duplicate ACK, it retransmits from the same place
each time.
I don't see what is broken about the remote end in this case.
> The problem is really that a TCP sender cannot recover from a too short RTT
> estimate; if the RTT is longer and it doesn't get any acks it'll assume
> packet loss and never has a chance to find out about the longer RTT, because
> that only works with new ACKs.
>
> The standard initial RTT is 3 seconds; but your RTT is 5.2s.
Actually, 5.2s is the most common packet interarrival time. The RTT is
more like 23s!
> What you can do is to change the initial RTT on the sender side. On Linux
> it can be done with the "irtt" option of route or the equivalent one of
> iproute2. Most other OS have a similar way to configure the IRTT.
Unfortunately I cannot change the IRTT on my ISP's mail server, or for
that matter on anyone's web server.
Are you saying that the IRTT must be larger than the actual RTT, and the
estimates can only go down? I thought IRTT was a rough guess and it
was expected to go either up or down.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:12 EST