Re: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update RFC 3717 (SACK-TCP)

["Scheffenegger, Richard" <[e-mail]>]

Hello Arnd,

Thanks for your comment; unfortunately, I'm not supposed to get
inspiration from GPL'ed code :) 


Do you know which kernel versions feature this? I've checked 2.6.16 and 
2.6.18 (commercial distributions), but none of the most recent ones...

FACK as described here
http://www.psc.edu/networking/papers/FACKnotes/current/
seems to be a sender-only algorithm; Thus if the receiver is
implementing
SACK, the sender should be able to use it, right?

I just rechecked - the trace does show the hallmark signs of FACK, but
no sign of
a retransmission of a lost retransmitted segment before a
(comparatively) long
Period (assuingly RTO) starting a limited slow start (as the slow start
ACKs
Are still SACKs for a large sequence space)...

(Using CentOS53, kernel 2.6.18 in this quick test).

Hmm... Running a 2nd check (this time with cached session parameters),
the
Linux Kernel seems to do a 2nd sack recovery - even though not optimally
so
(not at the very first possibility w/ 3 SACK-ACKs indicating that it 
would be possible...). The first trace appears to have run into a RTO
with
The very first dropped segment (and the stream took ages...)

3rd test: 237 msec delay (RTO?), with the last new segment being set 36
ms after
the 2nd drop (so, nearly exactly 200 ms after sending the last new
segment,
And receiveing about 80 uninterrupted ACKs...

So, the linux stack seems to have the capability, but it's not reliably
invoked...

Thanks for pointing this out!

Regarding the other two question - for the first one, please see
The diagram I sent earlier; I hope this clarifies what I mean.

If I am mistaken somewhere, please let me know...


And with the last statement (fastretransmission finished) I referred
To the point in time, when the sender has sent all segments being
flagged
By SACK to have been missing, before noticing (one RTT later) that
another
One might be missing; this might be a special case, though, as I assumed
That retransmission would end prior to the receiver detecting the 
2nd loss...

I guess a time-flow diagram would help :)

Best regards,


Richard Scheffenegger
Field Escalation Engineer
NetApp Global Support 
NetApp
[phone] Office (2143 3146 - internal)
[phone] Mobile
www.netapp.com 
Franz-Klein-Gasse 5
1190 Wien 


-----Original Message-----
From: Arnd Hannemann [mailto:[e-mail]] 
Sent: Montag, 9. November 2009 16:21
To: Scheffenegger, Richard
Cc: [e-mail]
Subject: Re: [tcpm] Should draft-ietf-tcpm-sack-recovery-entry update
RFC 3717 (SACK-TCP)

Scheffenegger, Richard schrieb:

> But what puzzles me the most - even with SACK enabled TCP stacks, 
> virtually no implementation can detect / act upon detection of the 
> loss of a retransmitted segment during fast recovery. This despite the

> fact, that the stipulations in
> RFC3517 requires the receiver to make the information to detect such 
> an event implicitly available to the sender. The first SACK option has

> to reflect the last segment, which triggered this SACK.

Some implementations actually do detect lost retransmissions.
(see Linux tcp_mark_lost_retrans())
However, currently only for FACK enabled flows. (Comments indicate, it
would be non-trivial / too-expensive for SACK enabled flows.)

> Together with the scoreboard held at the sender, it should be rather 
> easy to find out if the left edge of the lowest hole (relative to 
> stream octets) closes

> If that left edge stays constant for "DupThresh" number of ACKs, which

> reduce the overall number of octets in holes (any one hole might close

> due to the retransmitted packets still received), AND the sender 
> retransmits beginning with the lowest hole first, this would be a 
> clear indication of another segment retransmit loss...

Sorry, I don't understand. You mean "DupThresh" number of DupACKs?
Sack-blocks?
After which point in time? After the first retransmit?
SACK-blocks higher than recovery point? (the latter would make most
sense, IMO)

> Even a less speedy detection logic would work for SACK-enabled 
> sessions: once the fast recovery is finished from the sender's point 
> of view, if the receiver still complains about missing segments 
> (indicated by having the SACK rightmost edge - in the first slot SACK 
> option - at a segment higher than when fast recovery started), another

> round of fast recovery could be invoked, rather than waiting for RTO.

How can fast recovery be "finished" if the sender is missing packets?

Best regards,
Arnd Hannemann