>Let me try to reproduce here what I saw:
>
> [transfer was already running]
> 0 r -> l 0:1000 (1000)
> 0 ( 0) l -> r ACK 1000
> 100 ( 100) r -> l 1000:2000 (1000)
> 100 ( 0) l -> r ACK 2000
> 200 ( 100) r -> l 2000:3000 (1000)
> 200 ( 0) l -> r ACK 3000
> 300 ( 100) r -> l 3000:4000 (1000)
> 300 ( 0) l -> r ACK 4000
> 400 ( 100) r -> l 10000:11000 (1000)
> 400 ( 0) l -> r ACK 4000
> 500 ( 100) r -> l 11000:12000 (1000)
> 500 ( 0) l -> r ACK 4000
> 600 ( 100) r -> l 12000:13000 (1000)
> 600 ( 0) l -> r ACK 4000
>1200 ( 600) r -> l 4000:5000
>1700 ( 500) l -> r ACK 5000 <-
>2000 ( 300) r -> l 5000:6000 (1000)
>2500 ( 500) l -> r ACK 6000 <-
>...
If I understand well, this is exactly a fast retransmit case. Here why the
other hand must ignore the first two ack4000:
from rfc2001:
Since TCP does not know whether a duplicate ACK is caused by a lost
segment or just a reordering of segments, it waits for a small number
of duplicate ACKs to be received. It is assumed that if there is
just a reordering of the segments, there will be only one or two
duplicate ACKs before the reordered segment is processed, which will
then generate a new ACK. If three or more duplicate ACKs are
received in a row, it is a strong indication that a segment has been
lost. TCP then performs a retransmission of what appears to be the
And I don' t think the reason for the other end to continue sending data
is not delayed ack, but because it' s allowed send window is large.
Probably you can improve things decreasing your receieve window. I am not
a TCP expert though so I could be wrong here...
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/