congestion-control-charter.txt

Congestion Control and Loss Recovery (CCLR) Working Group charter
Alternate Name: Congestion and Loss Estimation, Adaptation, and Recovery (CLEAR)

The IETF has long been responsible for standardizing congestion control and loss
recovery algorithms on the internet. Traditionally, TCP was the user of these
congestion controls and new work on these subjects occurred in the TCP
Maintenance (TCPM) or Transport and Services (TSVWG) working group. When this
workflow was established, proposals typically emerged from research groups that
had limited ability and experience with running large scale tests to understand
the implications of their proposals. RFC5033 describes a Best Current Practice
to evaluate proposals for new congestion control algorithms to be evaluated for
Experimental or Proposed Standard RFCs. Meanwhile, tweaks to the loss recovery
standards have continued in TCPM.

In the IRTF, the Internet Congestion Control Research Group (ICCRG) has invited
talks on congestion control research and developments. Historically, it has not
produced documents despite the availability of the IRTF stream for Experimental
RFCs, although it may be rechartered to do so.

Over the last few years, several developments have raised questions about the
value of this model:

* The community working on congestion control, both industry and academia, now
has a much better understanding of the problem space, the likely issues, and how
to conduct large-scale tests to validate new designs. The degree of caution IETF
needs is lower, because our understanding has improved.

* IETF has standardized four transport protocols that use TCP-like congestion
controls: TCP, QUIC, SCTP, and DCCP. Non-TCP transports usually require their
own mechanism to adapt to TCP or TCP friendly congestion controls. Genuinely new
proposals tend to be done in reference to TCP only.

* Although numerous RFCs specify tweaks to congestion control and loss recovery,
the IETF has not published an Experimental RFC documenting a new general-purpose
congestion control since RFC 4782 in 2007.

* Among the most widely-deployed congestion controls today is Cubic, which was
developed without formal IETF review, deployed at scale (including as the
default in the Linux kernel and others), and much later acknowledged in
Informational RFC 8312 (a process to ratify the existing Cubic design as a
proposed standard, after the fact, is underway in TCPM).

* Large organizations that control their own transport implementations can and
do experiment with new congestion control concepts without conducting IETF
review, and generally present results from experiments at scale prior to any
such review.

* As the only Standards-Track general-purpose congestion control remains Reno,
other IETF standards reference it even though it is a small minority of internet
traffic today.

A separate working group can review some of the impediments to early congestion
control work occurring in the IETF, and generalize transport in this area from
TCP to all the relevant transport protocols. Accordingly, CCLR is chartered to
do the following work:

* Conduct a review of RFC5033 and consider a revision that relaxes requirements
to encourage more experiments in the IRTF/IETF. Coordinate with ICCRG to
determine a proper division of labor between IRTF stream and IETF stream
documents. For adoption of standards-track work, there should be a high bar
regarding intent to deploy by major transport implementations.

* Devise a framework for specifying congestion controls agnostic to protocol. It
might establish norms for when protocol-specific considerations are minor enough
to include in the base document, or protocol-specific documents are needed.

* TCPM will soon publish CUBIC as a TCP Proposed Standard. Apply the framework
above to adapt this specification to SCTP, QUIC, and DCCP.

While this charter does not specify further deliverables, CCLR is authorized to
adopt other work relating to Loss Recovery and Congestion Control without
rechartering. This work may be ongoing in TCPM, CORE, ICCRG, or elsewhere, and
if so, coordination is required to decide between adoption of the work and
consultation on it, based on its maturity, the quality of relevant review in
either venue, and its match with the CCLR adoption criteria. The following are
specifically in scope:

* New algorithms mature enough for standardization. CCLR may consider not only
the open internet, but also algorithms focused on Data Centers, “Controlled
environments”, Multipath, and Internet of Things use cases. Any adopted
document must be clear about the domains to which its operation is restricted.
Maturity can be judged on empirical evidence that the algorithm is safe and
beneficial to endpoints, as well as stated intent from stakeholders to deploy
the algorithm at scale.

* Tweaks to existing algorithms, such as Slow Start.

* New ways for endpoint to respond to both implicit and explicit congestion
signals.

* Progression of existing Informational or Experimental RFCs to higher maturity,
if they meet the criteria.

Proposals that depend on the capabilities of a single transport protocol should
generally remain in the working group for that protocol (i.e.. TCPM, QUIC,
TSVWG).

Interactive real-time, media adaptation algorithms for peer to peer
communication remain the focus of RMCAT and are not in scope. However, some
proposals for live streaming media adaptation may be applicable to both general
purpose and to RMCAT use cases, in which case CCLR can adopt them in
consultation with RMCAT.

Once the deliverables are complete, CCLR will not remain open simply “in case”
further work comes along. However, if the working group has adopted further
work in accordance with the guidelines above, it can recharter, add milestones
for them, and continue until that work is complete.