Re: [tcpm] Detect Lost Retransmit with SACK

[Alexander Zimmermann <[e-mail]>]

Hi Richard,

I discussed your example with Arnd (he is a line-of-sight colleague). Your "algorithms"
may workwhen you have only one bust lost per cwnd. If you have multiple non-burst
loss (e.g. WLAN), IMHO, is doesn't work.

Am 09.11.2009 um 18:27 schrieb Scheffenegger, Richard:

> 
> Hi Alexander,
> 
> Thanks for the welcome :)
> 
> I fork another thread with the LimitedTransport||FastRecovery / ABC interaction...
> 
> 
> I will try to sketch up an example to demonstrate what problem I'm trying to address:
> 
> 
> Let's assume the cwnd is already open for at least 7 segments, before the segment with
> sequence number 10000 is the first one to be dropped by the network.
> 
> Also, let's assume that FastRetransmit runs from the left edge of the leftmost hole
> (SND.UNA) upwards, and that per ACK only a single segment is sent.
> 
> 
>             Triggering    ACK      Left     Right    Left     Right
>             Segment                Edge 1   Edge 1   Edge 2   Edge 2
> 
>              9000          9000
>             10000  (lost)       *
>             11000  (lost)
>             12000  (lost)
>             13000  (lost)
>             14000  (lost)
>             15000         10000    15000    16000
>             16000         10000    15000    17000
>             17000         10000    15000    18000

Ok, I count 9 segments ;-) Anyway, your example is a little bit strange.
You assume you send 9 segment in a burst. Then your ACK for 9000 will trigger
the segment 18000. Then the 2 DUPACKs  for 15000 and 16000 will trigger 19000,
20000 respectively (Limited Transmit). The third DUPACK will trigger the Fast
Retransmit 10000. Since NextSeq() and pipe allow you retransmit 11000, 12000.

At this point you have to wait since the pipe is full (if I calculate pipe in a rush correctly).
A RTT later you will get 3 Dupacks, even if the 10000 is not lost.

OK, I think you can adjust your example so that it works for the given case, however in
other scenarios (multiple loss, reordering, packet duplication,...) it will be much more
complicated.

I suggest writing examples as Ilpo does in
http://tools.ietf.org/html/draft-ietf-tcpm-sack-recovery-entry-00.
It's much more easier to read.

> 
> 3 ACKs trigger fast retransmit
> 
>             10000  (lost again)
>             11000         10000    11000    12000    15000    18000
>             12000         10000    11000    13000    15000    18000
>             13000         10000    11000    14000    15000    18000
> -> here we have again 3 ACKs indicating a another loss of one of the retransmitted
> packets. The leftmost hole did not change, while the overall number of SACKed
> octets did decrease for 3 consecutive ACKs (4; 3 and 2 segments marked by SACK).
> 

Alex

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: [phone], fax: [phone]
// email: [e-mail]
// web: http://www.umic-mesh.net
//