2.7.3 Endpoint Congestion Management (ecm)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 26-Oct-99


Vern Paxson <vern@aciri.org>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Mailing Lists:

General Discussion:ecm@aciri.org
To Subscribe: ecm-request@aciri.org
In Body: (Un)Subscribe ecm your_email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/

Description of Working Group:

The Endpoint Congestion Management (ECM) Working Group has two goals:

1) To provide a standard set of congestion control algorithms that transport protocols can take advantage of rather than having to develop their own

2) To develop mechanisms for unifying congestion control across an appropriate subset of an endpoint's active unicast connections.

For ECM, we define a "congestion group" as one or more unicast connections communicating with a common destination, and for which a decision has been made to bundle the connections together into a single flow for purposes of congestion control.

For each congestion group, a Congestion Manager (CM) will track the capacity currently available along the network path(s) used by the group, based on congestion indications such as packet loss information, in a manner analogous to TCP's "congestion window". The CM will then pass this information along to a Scheduler module that determines how that capacity is to be partitioned among the connections in the congestion group.

Determining the granularity of "common destination" (e.g., particular subnet, CIDR mask, specific address, or specific address and range of ports), and making the decision as to which connections should be bundled together into a single congestion group and which go into separate groups, are both difficult problems, because they are heavily influenced by the specifics of both the remote network topology and by possibly-remote policy decisions. It is the hope of the IESG that the IRTF will undertake research into exploring how to address these issues. In the interim, the working group is charged with devising near-term solutions to these problems with sufficient flexibility to accommodate those possible alternative schemes sufficient flexibility to accommodate those possible alternative schemes that can be anticipated. The working group is also charged with maintaining good communications with the IRTF effort, should one materialize.

The CM architecture will stress separation of the mechanisms of determining the current available capacity from the policies of how to then schedule that capacity. It is a requirement that the architecture eventually apply both to TCP and to UDP-based (and other IP-based) transport that includes feedback information concerning congestion (e.g., packet loss or explicit congestion notification). The initial WG deliverables will focus on developing CM for unifying connections that either use TCP or use UDP in a style comparable with TCP in terms of detecting loss and measuring the round-trip time. It is possible that the scope of work will be extended in the future to also include mechanisms for applying congestion control to transports that do not include such feedback.

The WG is also tasked to investigate the architecture's security implications; and the degree to which network stability will be entrusted to correct operation of applications using ALF transports, rather than operating system kernels.

The WG will initially produce four documents:

- An Informational RFC on congestion control principles. The goal of this document is to explain the need for congestion control and what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control, including the sometimes elusive argument that congestion control is not needed because the protocol will only be run over well-provisioned paths.

- A Standards Track RFC describing the behavior of a standard-conforming Congestion Manager (how it decides the current available given congestion feedback from the members of a congestion group).

- A Standards Track RFC giving an abstract API for communication between Congestion Manager clients, the Congestion Manager, and the Scheduler. This initial work is confined in scope to supporting congestion groups made up of either TCP connections and/or UDP connections that incorporate the same sort of feedback (per packet loss information; RTT computation) as TCP.

- An Informational RFC giving an example of the behavior of one or more Schedulers.

Goals and Milestones:

Feb 00


Congestion control principles documented submitted to IESG for publication as Informational

Feb 00


Description of required behavior for Congestion Managers submitted to the IESG for publication as Proposed Standard

Feb 00


Abstract API for congestion management submitted to IESG for publication as Proposed Standard

May 00


Example description of behavior of ECM Scheduler submitted to the IESG for publication as Informational

Jun 00


Working Group rechartered with revised deliverables or shut down

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Endpoint Congestion Management
IETF 46 -- Washington DC
November, 1999
Chair: Vern Paxson

Reported by: Mark Allman (mallman@grc.nasa.gov)

Vern Paxson presented an overview of the working group and noted that the purpose of the meeting was to get everyone on the same page. The goals of the WG are to outline a set of congestion control (CC) algorithms that transport protocols can use rather than developing their own, and to develop ways to unify CC across connections. Vern noted that the granularity across which we share CC information is a difficult problem and the IRTF is being encouraged to examine the problem. Further, Vern noted that determining how much capacity exists on the network path needs to be orthogonal to scheduling which connection is allowed to use that capacity. The WG's scope is currently limited to protocols that have loss feedback. A comment was made that the WG is not looking at congestion control for the ACK stream or for streaming media such as video. Vern noted that we are doing what we understand, and encouraging the IRTF to investigate what we do not.

Next, Hari Balakrishnan presented an overview of draft-balakrishnan-cm-01.txt. Hari noted that the Congestion Manager (CM) now includes an API hook for setting the "macro-flow" (connections which have agreed to share network capacity). A question was raised about whether the API was rich enough to allow policy servers to inject rules about certain flows. Hari noted this as something to think about. A concern was raised because application designers need to worry about all these messy congestion control details. Hari noted that using the CM API is much easier than implementing the CC algorithms in the application. In response to another question, Hari noted that the current version of the CM is window based (as opposed to rate based). A point was raised that we may need to have a "no network" message, in addition to the "no loss" messages currently included in the draft. This thought was extended by Aaron Falk to include communication between the link layer and the transport layer. Hari noted that this was a nice thought, but is researchy and should be put off until later. Joe Touch voiced the opinion that some of the numbers in the API should include scale factors with them, or there is a chance that we'll outgrow this system in the future. A short discussion of security indicated that if an application lies about loss we may get nasty denial of service attacks. Vern noted that this is a hard problems and we do not yet have a good answer, but also that because CM needs to only be deployed on one endpoint in order to work, it has a relatively easy deployment and upgrade path.

Finally, Sally Floyd made a short presentation about draft-floyd-cong-00.txt, which is a general discussion of congestion control principles. Sally noted that traffic should be fair to TCP. Aaron Falk suggested that "fairness" is a researchy notion. Sally said that each proposal should be evaluated on its own and that "fair" does not have to be concretely nailed down. A question was raised about whether the CC principles applied to diffserv-like traffic. Sally indicated that they only apply to best effort traffic. Christian Huitema noted that since links to the home have very low bandwidth we are not in danger of congestion collapse from more aggressive TCPs and that the real solution to the problem is per flow scheduling. Sally disagreed, and the argument was made that even if this is the case, it's risky to bet the network's stability on this property. Hari Balakrishnan noted that we probably want both end-host mechanisms and router-based mechanisms.


None received.