Re: [tcpm] Detect Lost Retransmit mit SACK

[Arnd Hannemann <hannemann at i4.informatik.rwth-aachen.de>]

Hi Richard,


Scheffenegger, Richard schrieb:
> Hi Arnd,
> 
> Let's think about what would be required to track a lost retransmitted
> segment.
> 
> A) the sender can only know about this one RTT after it send out the
> first 
>    retransmission at the earliest.
> 
>   A1) With TSOpt, they could be used to "remember" when Retransmission
> started; 
>       When an ACKs with TSEcn > (TSOpt + RTT) is seen by the sender, it
> can 
>       re-arm the DUPACK detector.

This is your non-SACK scenario?
Please note that a TCP receiver will NOT echo TSVal
from out-of-order segments. So this won't work.

>   A2) With SACK, tracking SND.NXT and HOLEBYTES (number of octets in all
> current holes) 
>       can be employed to track RTT (they need to be initialized when the
> first 
>       retransmitted segment is sent). When an ACK contains a SACK for >=
> SND.NXT, or the 
>       HOLEBYTES are smaller than when retransmission started, the DUPACK
> detector can 
>       be re-armed.

You should specify what you mean with SND.NXT.
We are in recovery, so we may very well send out new segments.
I don't see why number of holes in sack scoreboard
has anything todo with RTT.

> 
>   A3) If neither TSOpt nor SACK is used, revert to current behavior (RTO
> timeout to
>       detect a lost retransmit).
> 
> B) DUPACK detector would need to be enhanced over what is currently in
> the RFCs (but 
>    I think most of that is already in Drafts, ie. 
>    http://tools.ietf.org/html/draft-jarvinen-tcpm-sack-recovery-entry-01
> ).
> 
>  B1) With SACK enabled, fully duplicate ACKs (ACK and SACK have been
> seen before, and 
>      prev_HOLEBYTES == HOLEBYTES) can be discarded; lost ACKs would
> count for two 
>      (prev_HOLEBYTES < HOLEBYTES - SMSS).

Now B1 is SACK enabled scenario? You try to confuse me, right?
All this makes little sense to me.

> 
>  B2) With TSOpt, if another RTT passes without advancing SND.UNA, 
>      increase DupAcks += DupThresh 
> 
>  When DupThresh # of ACKs are received, reset HighRxt = SND.UNA, DupAcks
> = 0; *)

See above...
non-SACK is not going to work.


> There are two comments I would like to make:
> 
> A) Latency: if the sender first sends out the entire range of holes,
> before
>    reacting to a detectable lost retransmitted packet, the latency
> observed
>    by the application on the receiver side will increase needlessly. It
> might
>    take a number of RTTs under certain circumstances, before all the
> holes
>    have been retransmitted once... 

Show me an example. where a lost retransmission is detectable, while
the sender did not send out retransmissions for every other hole?
Sounds weird.


> 
> B) Complexity: As soon as any congestion event is encountered, TCP won't
> be in
>    fastpath mode any longer; the added computational complexity to
> (reliably, see my
>    check on FACK with Linux 2.6.18 yesterday) trigger another
> retransmission
>    of an already retransmitted segment is neglegible, compared to
> current best
>    practise (waiting for RTO), when you need to move data around as
> quickly (low
>    latency AND high bandwidth) as possible. As mentioned, my background
> is not
>    so much the global internet (with statistically valid implict
> assumptions), but
>    rather High-Speed, short Range, (lossy) LANs, with only very few
> active TCP
>    sessions at any one time. The hosts I deal with might have as few as
> 10-20 TCP
>    sessions, of which only 1-4 are pushing data, but those might run
> over dedicated
>    10GbE ports (overloading L2 switches in the process, and exhibiting
> Burst Loss
>    (correlated packet loss) ).

This probably highly rates from case to case. If you have a huge
bandwidth-delay product even SACK scoreboard handling will have
computational complexity which might outweigh its benefits.
As you have seem to have the equipment at hand, you could do some
cpu load and throughput measurements with 10GbE
and SACK versus non-SACK flows.


> 
> 
> Thus my view might deviate from a "typical" view in certain aspects. I
> might even be 
> in error and would like to hear, why some things cann't work like
> depicted. However, 
> I would place more emphasis on the timely recovery  of any lost (or
> re-lost) segment, 
> over making sure that no single segment is re-transmitted needlessly;
> better retransmit 
> a little (!) too much too soon, instead of waiting for RTO :) I want to
> point out the 
> "little" though, as overwhelming a already lossy network with too much
> retransmissions 
> (ie. Setting RTO = 0/1 tick, with a TCP clock runnig in msec), will only
> cause more loss...
> 

I think it is a good idea to detect lost retransmissions and I think
it is possible with SACK. I already proposed a potential solution ;-)
"Just" store highest seq, for each retransmission. And check incoming SACKs
on those. My main concern is, as already said, that this might get
quiet expensive. But you are free to evaluate this more deeply ;-)
Anyway, maybe we should focus on your other thread...

Best regards,
Arnd