Subject: draft-ietf-ecm-cm-00.txt submitted

From: Hari Balakrishnan <[email-masked]>
Date: Sun, 02 Jul 2000 12:16:56 -0400

Srini and I just submitted a new draft of the Congestion Manager I-D (new draft 
name in subject line).  It is also available from http://nms.lcs.mit.edu/papers/
draft-ietf-ecm-cm-00.txt

We'd like to get some discussion on it before the Pittsburgh IETF meeting.  To 
this end, I'll summarize the issues in two parts: (I) open issues and (II) 
changes from previous version.  (These points will make more sense after 
reading or at least perusing the submitted draft.)

(I) Open issues

1. Prioritization.

In the current CM draft, ALL transmissions have to be OK'd by the CM, which 
implements a TCP-like window-based algorithm (this last part isn't a 
requirement, but we expect many implementations to do this).

Howeve, this sometimes causes a small problem, which needs to be addressed by 
the group.  It is best illustrated via an example, of TCP retransmissions 
(assume no SACK).

When TCP (Section 6.1.1) recognizes that data has been lost in the network, it 
first uses cm_update() to inform CM of the loss and, as a result, CM performs 
congestion control (e.g., window-halving).  At this point, CM believes that it 
has much more data in the "network pipe" than its congestion estimates allow.

TCP then performs a cm_request() in order to schedule the *retransmission* of 
the lost data.  However, due to the state of the CM, this request is unlikely 
to get served for quite some time.  Since TCP does not get new ACKs, it passes 
little new information to CM and the whole process gets stalled.

We handle this in our current TCP/CM implementation by bypassing the CM while 
performing TCP retransmissions---they do not wait for a cm_request() to be 
satisfied.  Retransmissions are sent immediately and essentially ignore the CM.

This sounds like a hack (it is) and we need a clean way to handle this, perhaps 
by extending the API.  In general, some modifications need to be made to 
support any application that *really* needs to send a packet to make progress 
or obtain additional feedback. One possibility is to add a priority parameter 
to cm_request() and allow a single high priorty packet to be sent every RTT, 
independent of the current congestion state.  This would allow applications 
like TCP to schedule retransmissions through the CM.  It might even be 
necessary to restrict access to this to specific protocols (e.g., in-kernel 
apps).

Your thoughts on this would be quite valuable.

2. Buffered transmissions.

See Section 4.2.

The previous CM draft had three types of transmission APIs.  The callback API 
using cm_request/cmapp_send; the synchronous API using cmapp_update(); and a 
buffered cm_send API.  In the current draft, we removed the third option.  The 
reason is that we found it to be simpler and more elegant to implement buffered 
congestion-controlled transmissions as part of UDP rather than in the core CM.

The advantage of this mechanism is that the CM is simple, and conformant CM 
implementations are easier to develop; the disadvantage is that the onus for 
providing congestion-controlled buffered transmissions is pushed to individual 
transports.  As it turns out, it isn't too hard to implement this for UDP, 
providing congestion-controlled UDP sockets.

Do you see any architectural or other drawbacks of this decision.

3. Default granularity.

See Section 4.5

This issue has arisen several times on the list.  The submitted draft has the 
following comment about default granularity:

   The default suggested aggregation method is to aggregate by
   destination; i.e., all streams to the same destination are
   aggregated to a single macroflow by default.  The cm_getmacroflow()
   and cm_setmacroflow() calls can then be used to change this as
   needed. 

Does the group agree with this, or should it be replaced with a default 
macroflow granularity of single streams, with the API calls being used on a 
per-application basis to change the granularity?

(II) Summary of changes

1. Many issues pointed out by Vern (message sent to the list on Fri, 16 Jun 
2000 15:47:33 PDT (18:47 EDT)) addressed and his comments incorporated; other 
comments from private email incorporated.

2. cm_send() eliminated; added section on congestion-controlled UDP as a CM 
application.

3. Clarified TCP description.

4. Fixed many references.

For the extremely curious, context diffs between the previous and current 
versions are at http://nms.lcs.mit.edu/papers/cm-draft-diffs.txt

Also, there's a technical report on our implementation, performance and 
efficiency considerations at http://nms.lcs.mit.edu/papers/MIT-LCS-TR-808.ps.gz
(this is an older version of a paper in preparation that will appear at OSDI 
2000).

Thanks,
Hari & Srini