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

[Neal Cardwell <[e-mail]>]

On Fri, Mar 12, 2021 at 3:39 PM Scheffenegger, Richard <[e-mail]> wrote:
>
> 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

FWIW looks like there is a copy of the [SACKPerf] paper here:
  http://www.hep.man.ac.uk/g/GDARN-IT/pfldnet2008/paper/kodama_y%20Final.pdf

> 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).

Oh, interesting. Maybe so. I have not had time to read the paper or
the preceding code.

> 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?

Yes, that sounds correct. In Linux Reno/CUBIC/etc there would only be
one cwnd reduction until SND.UNA reaches the value SND.NXT had at the
time of the previous reduction. That is, there is one cwnd reduction
per "window", where "window" is interpreted in sequence space rather
than time.

> 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.

I have not had the time to read the [SACKPerf] paper that seems key to
this archeology, so would defer to your wording. Thanks for your
generous offer, but my plate is a bit full at the moment.

> 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.

Sounds interesting. I would agree that documenting something close to
the existing LRD algorithm that has a lot of air miles from 2008 until
RACK seems like a good place to start.

best regards,
neal


> 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
> >