Subject: draft minutes for this month's ECM meeting

From: Vern Paxson <[email-masked]>
Date: Mon, 29 Nov 1999 16:40:49 PST

Sorry these took a while.  If you have comments, please send them soon!

		Vern

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

Reported by: Mark Allman ([email-masked]) 

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.