Re: [tcpm] New draft: https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00

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

Hi Neal,

I was specifically thinking about Linux, but my recollection as to when
it first showed up there must have been skewed.

The SACKPerf reference appears to be dead (only a copy on archive.org is
available - I don't know if that is valid to quote instead of the link
that I found all these years ago.

https://web.archive.org/web/20150103014718/http://projects.itri.aist.go.jp/gnet/sack-bug.html

In any case, the improvement described therein sounds as if some more
limited form of lost retransmission detection was already present in
Linux before that. (For single Hole/SACK Ranges).

As I am not that intricately familiar with Linux, is my assesment
correct that (at the time of ~2.6.24), CC would not be triggered anew
when a lost retransmission is detected?

If you have a suggestion for an appropriate text honoring all the prior
work on Linux, I would be very grateful. I would also like to invite you
to coauthor this document, if you want to help refine the text further.


Also, I have a more aggressive mechanism, using a heuristic to
differentiate between a SACK for an original segment vs. a SACK for a
retransmitted segment, and using the latter to also engage LRD. As this
variant does not rely on new data to be sent, it can also work at the
end-of-stream, albeit with some potential misdetections of lost
retransmissions (again superceded by TLP /  RACK).

However, I felt that the conservative mechanism is the proper starting
point for now.

Best regards,
    Richard



Am 12.03.2021 um 19:26 schrieb Neal Cardwell:
>
>
> On Fri, Mar 12, 2021 at 12:34 PM Scheffenegger, Richard <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>     After some discussion, I got convinced to formally submit a draft,
>     explicitly describing a simple lost retransmission detection mechanism
>     to prevent RTO when a retransmission is lost.
>
>     While full featured stacks can address this issue within the RFC series
>     already by using TCP RACK, on a more constrained platform where only
>     SACK support is viable but not RACK, this mechanism may be an
>     interesting alternative.
>
>     Thererfore cross-posting to CORE, in addition to TCPM. ICCRG is
>     included, as it may be the case that current implementations which
>     recover from lost retransmissions may not actually use this as a
>     subsequent congestion control signal, and retain the ssthresh / cwnd
>     from the initial loss recovery - and it is certainly debatable, if
>     a single, or two engagements of a CC reaction is in order.
>
>     The mechansim described is very conservative (another CC reaction, and
>     requires more data to be sent, to have high confidence when
>     retransmitting a prior retransmission).
>
>     https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00 <https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00>
>
>     (The graph in the appendix needs some overhaul, as PRR is becoming
>     standard).
>
>
> Thanks for the ID!
>
> Indeed this could be a useful algorithm to document for nodes too
> constrained to run RACK.
>
> You mention in the ID that there is a TCP stack that "started using LRD
> more than two decades ago." Just curious: is that FreeBSD?
>
> This approach sounds similar to (a) the improvement in the paper that
> your informative references cite as [SACKPerf], and similar to (b) the
> algorithm added in Linux 2.6.24 in 2008 in  tcp_mark_lost_retrans()
>   (later removed in the era of RACK). And it seems perhaps (a) and (b)
> are roughly the same thing, since the [SACKPerf] paper mentions their
> idea was incorporated into Linux 2.6.24? But I wasn't sure what the
> relationship is.
>
> I did not see [SACKPerf] mentioned in the body of the ID. Would it be
> possible to add some text in the ID that mentions [SACKPerf] and
> clarifies the relationship of the ID to the [SACKPerf] paper and Linux code?
>
> best regards,
> neal
>