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 protected]> An: iccrg IRTF list <[email protected]>, tcpm IETF list <[email protected]>, [email protected] 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 _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
