TCP Maintenance and Minor Extensions (tcpm) Internet Drafts

	More Accurate Explicit Congestion Notification (ECN) Feedback in TCP
	draft-ietf-tcpm-accurate-ecn-28.txt   Date: 17/11/2023   Authors: Bob Briscoe, Mirja Kuehlewind, Richard Scheffenegger   Working Group: TCP Maintenance and Minor Extensions (tcpm)	Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets instead of dropping them to indicate incipient congestion to the endpoints. Receivers with an ECN-capable transport protocol feed back this information to the sender. ECN was originally specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recent new TCP mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) or Low Latency, Low Loss, and Scalable Throughput (L4S) need more accurate ECN feedback information whenever more than one marking is received in one RTT. This document updates the original ECN specification in RFC 3168 to specify a scheme that provides more than one feedback signal per RTT in the TCP header. Given TCP header space is scarce, it allocates a reserved header bit previously assigned to the ECN-Nonce. It also overloads the two existing ECN flags in the TCP header. The resulting extra space is exploited to feed back the IP-ECN field received during the 3-way handshake as well. Supplementary feedback information can optionally be provided in two new TCP option alternatives, which are never used on the TCP SYN. The document also specifies the treatment of this updated TCP wire protocol by middleboxes.
	ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets
	draft-ietf-tcpm-generalized-ecn-15.txt   Date: 02/12/2023   Authors: Marcelo Bagnulo, Bob Briscoe   Working Group: TCP Maintenance and Minor Extensions (tcpm)	This document specifies an experimental modification to ECN when used with TCP. It allows the use of ECN in the IP header of the following TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and retransmissions. This specification obsoletes RFC5562, which described a different way to use ECN on SYN/ACKs alone.
	A YANG Model for Transmission Control Protocol (TCP) Configuration and State
	draft-ietf-tcpm-yang-tcp-09.txt   Date: 11/09/2022   Authors: Michael Scharf, Mahesh Jethanandani, Vishal Murgai   Working Group: TCP Maintenance and Minor Extensions (tcpm)	This document specifies a minimal YANG model for TCP on devices that are configured and managed by network management protocols. The YANG model defines a container for all TCP connections, and groupings of authentication parameters that can be imported and used in TCP implementations or by other models that need to configure TCP parameters. The model also includes basic TCP statistics. The model is compliant with Network Management Datastore Architecture (NMDA) (RFC 8342).
	Proportional Rate Reduction for TCP
	draft-ietf-tcpm-prr-rfc6937bis-08.txt   Date: 16/03/2024   Authors: Matt Mathis, Nandita Dukkipati, Yuchung Cheng, Neal Cardwell   Working Group: TCP Maintenance and Minor Extensions (tcpm)	This document updates the experimental Proportional Rate Reduction (PRR) algorithm, described RFC 6937, to standards track. PRR provides logic to regulate the amount of data sent by TCP or other transport protocols during fast recovery. PRR accurately regulates the actual flight size through recovery such that at the end of recovery it will be as close as possible to the slow start threshold (ssthresh), as determined by the congestion control algorithm.
	TCP ACK Rate Request Option
	draft-ietf-tcpm-ack-rate-request-04.txt   Date: 02/03/2024   Authors: Carles Gomez, Jon Crowcroft   Working Group: TCP Maintenance and Minor Extensions (tcpm)	TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to request the ACK rate to be used by a receiver, and it also allows to request immediate ACKs from a receiver.

data-group-menu-data-url="/group/groupmenu.json"> Skip to main content