CONGestion RESponse and Signaling
charter-ietf-congress-00-00

Work on congestion control usually occurs in the TCP Maintenance (TCPM) or
Transport and Services (TSVWG) working groups. RFC 5033 describes a Best Current
Practice to evaluate new congestion control algorithms as Experimental or
Proposed Standard RFCs. When this workflow was established, TCP was the dominant
consumer of this work, and proposals typically emerged from research groups that
had limited ability and experience with running large scale tests to understand
the implications of their proposals.

In the IRTF, the Internet Congestion Control Research Group (ICCRG) has invited
talks on congestion control research, but has only rarely published documents
despite the authority to produce Informational and Experimental RFCs.

Since RFC 5033 was published, many of these conditions have changed. Proponents
often have the opportunity to test and deploy at scale without IETF review. The
set of protocols using these algorithms has spread beyond TCP and SCTP to
include DCCP, QUIC, and beyond. There is more interest in specialized use cases
such as data centers and real-time protocols. Finally, the community has gained
much more experience with indications of congestion beyond packet loss.

The CONGestion RESponse and Signaling working group (CONGRESS) can review some
of the impediments to early congestion control work occurring in the IETF, and
can generalize transport in this area from TCP to all of the relevant transport
protocols. The congestion control expertise in the working group would also
make it a natural venue to take on other work related to indications of
congestion, such as delay, and potentially queueing algorithms.

Accordingly, CONGRESS is chartered to conduct a review of RFC 5033 and to
consider a revision that relaxes requirements to encourage more experiments in
the IRTF/IETF.

CONGRESS is authorized to adopt other work relating to Congestion Control and AQM without rechartering.
Adoption of standards-track work for congestion control algorithm should consider (1) empirical
evidence of safety and (2) stated intent to deploy by major transport
implementations.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 CONGRESS adoption criteria to be enumerated in the
RFC 5033 update. The following are specifically in scope:

• Algorithms mature enough for standardization. CONGRESS may consider not
  only the open Internet, but also algorithms focused on other deployment models
  (e.g. datacenters and other controlled environments, reduced resource
  deployments such as IoT, and so on). Any adopted document must be clear about
  the domains to which its operation is restricted, and any such restriction
  requires approval of the Responsible AD.

• Algorithms proposed for Experimental status, in consultation with ICCRG, based
  on an assessment of their maturity and likelihood of near-term wide-scale
  deployment.

• Multipath congestion control.

• Active Queue Managment (AQM) and Fair Queueing (FQ) algorithms, in
  consultation with TSVWG, based on the available time and reviewing expertise in
  both groups.

• Rate pacing, including bandwidth estimation techniques that inform it.

• Tweaks to existing algorithms, such as Slow Start.

• Techniques to address lower-layer alterations to packet timing or ordering.

• New ways for endpoints to respond to both implicit and explicit congestion
  signals, including specification of explicit signals.

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

• Operational guidance, in general, including advice to upper layers or new
  transport protocols. Examples include minimum frequency of feedback,
  counterproductive application retransmissions and multiple connections to the
  same host.

Proposals that depend on the capabilities of a single transport protocol should
generally remain in the maintenance working group for that protocol (i.e.,
TCPM, QUIC, TSVWG). Documents in CONGRESS should remain as independent of
transport protocol as possible, but they might have short specific instructions
(e.g. a header option or parameter format) for one or more protocols.

CONGRESS is not chartered to publish Informational RFCs documenting the state of
congestion control in the Internet, including assessments of compliance with
existing standards. Other venues, e.g., IRTF, may be more appropriate for
publishing such documents.

Real-time, media adaptation algorithms for peer to peer communications remain
the focus of RMCAT, but are in scope after that WG closes.

Once the chartered deliverables are complete, CONGRESS 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.