Re: [tcpm] Detect Lost Retransmit mit SACK

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

Hi Richard,

Scheffenegger, Richard schrieb:
>>>   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.
>>     
>
> Interesting; this doesn't seem to be what certain (most?) stacks are 
> doing - they seem to always reply in the ACK Tsecr the value of
> Tsopt/TS.recent 
> triggering the ACK...

Please clarify, is this non-SACK scenario?
The only lost retransmission we could be talking about then,
is the retransmission of SND.UNA.
And the TCP receiver will NOT adjust TS.recent for any
out-of order packets (RFC 1323).
It will continue to echo the timestamp of the last segment which
advanced the window (SND.UNA -1p).


> Or was your intention to say, that the receiver will not respond with
> Tsopt, but rather TS.recent?

Yes, it will not respond with TSVal but with TS.recent.

> If so, than this makes no difference - the sender will detect the 
> first ACK from the receiver, which has the same TS (well, actually TS+1
> as multiple segments are likely to carry the same TS) when the
> retransmission

There won't be an ACK if the retransmission is lost in non-SACK
case, only dupACKs.
(Only retransmission is retransmission of SND.UNA)
TS.Recent will not get updated.


> was started. This will be the sign for the sender, that at least one RTT
> has elapsed (that was the intention for having timestamps in the first
> place, right?). If the returned ACK does not cover the first
> retransmitted
> segment by that time, it's quite reasonable to assume that it got lost
> again
>   

> Again, keep in mind that I'm looking on LANs; a TS in 10 ms increments

If you are searching for something which is not intended for general use,
why not just set MIN_RTO to say 10 ms?

>>>   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.
>>     
>
>
> SND.NXT is the rightmost segment which the sender has never before 
> sent out to the network. Isn't that the meaning of Snd.nxt according 
> to RFC793?

Hmm, I would interpret RFC793 differently.
I would call it SND.MAX (see RFC4015) or HighData (RFC3517) the
rightmost segment which the sender has never sent before. But now you
have to clarify how it would be possible to receive a
SACK block > SND.MAX. Even SACK block == SND.MAX will be rarely seen.
But before taking this discussion even further, maybe take some time
and write some preliminary draft of your algorithm.

> And I was not talking about the # of holes, but rather the amount of
> Data (in sum) between FACK (defined by the rightmost offset in the SACK
> Scoreboard, i.e. covering the highest ever received segment) and
> SND.UNA.
>
> Monitoring Holes will gain nothing (when there is reordering for
> example);
>
> But if the any one retransmission makes it though, the amount of
> unSACKed 
> data in the sum total of all holes in the scoreboard, will decrease - 
> indicating when at least one RTT has passed since start of
> FastRetransmit.

This is not true.
Consider a 100 packet in flight, you get 3 dupacks, do  a retransmission.
This is in your words "start of FastRetransmit". After this the sum total
of all holes between SND.UNA and FACK can only increase for one RTT.
Due to Limited Transmit and Fast Recovery, it might be possible that
even the sum total of all holes between SND.UNA and SND.MAX will
increase.
You know when the first Retransmit is lost when a SACK
covers RecoveryPoint (RFC3517). But this is only true for first hole.
To detect lost retransmissions of the other holes, you would
need to store a separate HighData (RFC3617) for every retransmission.
Maybe this is after all what you are trying to express?
Perhaps it would be helpful if you could cook up some pseudo code,
of your proposed algorithm.

>>     
>>> 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.
>>     
>
> Can I attach trace files on posts to this list, or shall I sent them 
> to you directly? 

Never mind, does not actually matter.

>>>       
>> 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.
>>     
>
> Well, I was doing some test like this:
>
> http://www.ibm.com/developerworks/linux/library/l-tcp-sack/index.html
>
> But the CPU impact (on top of what is required for 10G) was neglegible.
> But I have to admit, I didn't had the time yet to test a SACK scoreboard
> with every other byte marked mission (which could mean some 0,5 mio
> entries).
>
> But it seems that most implementations feature sorted scoreboards of
> limited
> (16/128) size.
>
> Traversing those is - again in my case of 10G LANs - still many orders
> of 
> magnitude faster then waiting for RTO. 
>
> I personally consider RTOs to be harmful (when there are other means to 
> recover with). :) (perhaps once I have worked through all the issues
> raised
> here, I submit a draft with "TCP RTO considered harmful" next April? :)

Better submit a draft to mitigate the problems with it ;-)

Best regards,
Arnd