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

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 12 Mar 2021 21:45:52 +0100

Hi,

One of the co-chairs of TCPM asked me, to forward this notification also
to the lwig (lwip) WG, in addition to core, as it describes a less
heavy-weight scheme to timely recover from lost retransmissions.

I am not sure how prevalent TCP SACK in either core or lwig related
environments is, though. But even a simple constrained SACK
implementation may benefit from this new mechanism.

Best regards,
    Richard

-------- Weitergeleitete Nachricht --------
Betreff: [tcpm] New draft:
https://datatracker.ietf.org/doc/html/draft-scheffenegger-tcpm-lrd-00
Datum: Fri, 12 Mar 2021 18:33:40 +0100
Von: Scheffenegger, Richard <[email-masked]>
An: iccrg IRTF list <[email-masked]>, tcpm IETF list <[email-masked]>,
[email-masked]

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

Best regards,
    Richard