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

[Arnd Hannemann <[e-mail]>]

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