CONGestion RESponse and Signaling (congress)

WG Name CONGestion RESponse and Signaling
Acronym congress
Area Transport Area (tsv)
State Abandoned
Charter charter-ietf-congress-00-01 Not currently under review
Document dependencies
Personnel Chairs Eric Kinnear, Reese Enghardt
Area Director Zaheduzzaman Sarker
Mailing list Address congress@ietf.org
Archive https://mailarchive.ietf.org/arch/browse/congress/
Chat Room address https://zulip.ietf.org/#narrow/stream/congress

Charter for Working Group

CONGestion RESponse and Signaling Working Group Charter (CONGRESS)

RFC 5033 describes a Best Current
Practice to evaluate new congestion control algorithms as Experimental or
Proposed Standard RFCs. TCP was the dominant
consumer of this work, and proposals were typically discussed in research groups (for example, Internet Congestion Control Research Group - ICCRG).

Since RFC 5033 was published, many conditions have changed. Congestion control algorithm proponents
now 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.

CONGRESS is chartered to conduct a revision of RFC 5033. The working group should

consider a revision that relaxes requirements to encourage more experiments in
the IRTF/IETF. Adoption of standards-track congestion control algorithms should consider (1) empirical

evidence of safety (for example - avoiding congestion collapse) and (2) stated intent to deploy by major transport
implementations.

CONGRESS is authorized to adopt work relating to Congestion Control and AQM 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 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.

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

  • Real-time, media adaptation algorithms for peer to peer communications

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

CONGRESS will not remain open simply because “in case” further work comes along.