CONGestion RESponse and Signaling
|Document||Proposed charter||CONGestion RESponse and Signaling WG (congress)|
|Title||CONGestion RESponse and Signaling|
|State||Start Chartering/Rechartering (Internal Steering Group/IAB Review) Initial chartering|
|IESG||Responsible AD||Zaheduzzaman Sarker|
|Charter edit AD||Zaheduzzaman Sarker|
Has 2 BLOCKs. Has enough positions to pass once BLOCK positions are resolved.
|Send notices to||(None)|
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.
|Last Next||Submit 5033bis to IESG|