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 12:34 PM Scheffenegger, Richard <[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
>
> (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