Datagram Congestion Control Working Group
IETF-54, Yokohama, Japan
Monday, July 15, 2002
Aaron Falk, notes taken by Dave Plonka and Spencer Dawkins

NOTE: These minutes only summarize the contents of the slide presentations given in the meeting.  Readers will find these minutes more useful if they review the presentations.  Copies may be found at
http://www.icir.org/kohler/dcp/

=============

Meeting agenda:

0. Agenda Bashing (falk)

1. Charter Review (falk)
   homework: DCCP Charter:
        http://www.ietf.org/html.charters/dccp-charter.html

2. First milestone: Is the requirements/functional summary in the problem statement complete? (floyd)
   homework:
        DCCP Problem Statement:
	draft-floyd-dcp-problem-00.txt

3. Significant changes in spec (kohler)
   homework:
        Datagram Congestion Control Protocol:
	draft-kohler-dcp-04.txt

        TFRC Congestion Control Profile:
	draft-padhye-dcp-ccid3-04.txt

        TCP-like Congestion Control Profile:
	draft-floyd-dcp-ccid2-03.txt

4. Open Issues (kohler, summarizing from list)

5. Implementation Reports
        (none as of 7/3/02)

6. Adjourn

======================

Meeting notes:

1. Charter Review (led by Aaron Falk):

Aaron walked through the DCCP charter including the motivation, scope, deliverables, and schedule.  Additionally, the mail list has been moved from dcp@ietf.org to dccp@ietf.org and subscribers to the old list do not need to resubscribe.

  Discussion

  Bob Braden: Is there a reason for not publishing the requirements summary as an informational RFC.

    Aaron: There was no strong feeling that the document should *not* be published.  It may be submitted as an individual submission to the RFC Editor for Informational RFC publication, however.

2. Problem Statement (led by Sally Floyd):

Sally discussed the DCCP requirements, constraints, and design rationale, all covered in draft-floyd-dcp-problem-00.txt.  She solicited input on whether the problem, constraints, and requirements were correct.  Aaron pointed out that the schedule requires the protocol requirements discussion to be completed by September, encouraging review and discussion of Sally's doc.

  Discussion

  Spencer Dawkins: offered to review the RUTS bof minutes for "things that people hated about TCP" as potential requirements for DCCP.

    Sally: Great idea.

3. Spec Changes (led by Eddie Kohler):

Eddie reviewed document and protocol changes since the dccp bof for the core DCCP spec.  The CCID 0 spec has been killed because it was more trouble than it was worth.  Input was solicited on the issues of whether the connection nonce provided more or less security than the TCP pseudo-header.

He also solicited input on the following open issues:

  o It was highlighted on the mail list that there is a possible DCCP name conflict for ethereal users.  Eddie could not find documentation of this and recommended not making additional name changes.

  o Should there be an (socket) API specified and, if so, in what document should it be captured?  Also, while sockets will be used for connection setup and tear-down, are kernel upcalls desirable for other kernel-application communication.

      Stuart Cheshire: encouraged the use of upcalls.

  o Some concerns were raised at the DCCP bof that having sequence numbers in DCCP and RTP might result in enough excessive overhead that RTP applications wouldn't want to use DCCP.  The sequence numbers are used for different reasons and in different ways (e.g., non-data packets in DCCP get sequence numbers which RTP would never see).  There are two options: the baseline, with sequence numbers in both protocols, or encouraging a new version of RTP that uses the DCCP sequence numbers.

    Jim Renkel: Should this question be in AVT WG instead of here?  Seems to me RTP adaptation should be done by RTP folks in AVT.

      Aaron: Multimedia streams represent a key application for DCCP. If the protocol has too much overhead (as perceived by the RTP users), we could be wasting our time building a protocol no one will use.

    Steve Casner: There could be version of RTP for use on DCCP, but done later, as an optimization.  At this point, the input from the RTP folks should just be used to be sure the right stuff is in DCCP.  Also, the extra space cost should not overwhelming issue: 12-byte RTP overhead is even considered too much by some folks in AVT.  I.e. this is a contentious issue.

    Fred Baker: Primary issue isn't that apps are BW-sensitive, the primary issue is latency/jitter.

      Aaron: DCCP focuses on unreliable, out of order delivery etc. and shouldn't introduce any latency other than due to congestion control.

      Fred Baker: Congestion has many causes (not just things the kernel knows about).  <something about Diffserv, RSVP and APIs>

      Sally: DCCP is meant to be used by Best Effort as well as other traffic

    Steve: be careful with the design of an API.  RTP doesn't have one because it had to be flexible and integrate tightly with applications.

    Melinda Shore: header size *does* matter.  With tunneling and such, we're sending "voice headergrams."  Active applications have been slow to develop, perhaps cc friendly transport is a good thing.

    Mike Luby: TCP has average throughput inversely proportional to RTT.  Have you looked at other transports which don't have this property.

      Sally: a good research question and good for future consideration. And burden of proof for new congestion control mechanisms is on the proposers.

      Mike Luby: This is the opp'y... perhaps a building block approach to be able to use other/ later CC mechanism for multimedia apps

      Eddie Kohler: non TCP-like CC is going to take a long while in IETF

      Aaron: CCIDs are separate drafts.  To pursue this you could propose a new CCID.

        Sally: Or perhaps that should be done in TSV WG, e.g. as a consideration of alternatives for TCP

    Spencer: look at interactions between ROHC header compression and DCCP. E.g.,  RTP ROHC work.

  o There have been several requested extensions to the protocol.  The criteria for inclusion has been 'only if you can't efficiently provide it at a higher layer' to keep the protocol as simple as possible.  Extensions which have been suggested, but not included, so far include flow multiplexing, fragmentation, and selective reliability.

    Sunay Tripathy: Do you have a proposed application for these extensions? Strongly recommend keeping things simple.

      Aaron: Multiplexing came out of the Salt Lake City BOF.

      Eddie: Applications are prevented from sending larger-than-MTU packets (not true of UDP), because this toasts the congestion control interactions. There is diversity among draft authors on most of these extensions.

    Melinda Shore: UDP fragmentation is a problem for cheap NATs which are stateless, because they don’t know what to do with any fragment after the first fragment.

      Eddie: This isn’t going to be as big a problem unless a firewall has to look at the application payload. DCCP fragments will have full DCCP headers on each fragment, so this will work better across cheap NATs.

    Colin Perkins: Fragmentation of a media stream won’t be useful because players can’t play a fragment by itself anyway.

    Eddie: Need more work on security aspects of fragmentation.

  o Other issues that may not be fully baked, but that *are* in the current spec are quiescence, connection proof, and slow receiver.  Feedback is welcome on these issues.

4. Implementation Reports (led by Eddie Kohler)

  There are two known implementation efforts: one by Patrick McManus in the Linux kernel and one at Berkeley at user level (limited, does CCID 3), which may be moved into a kernel.  Pointers on DCCP web page.  Neither implements quiescence.  (Neither implementers were in the room.)

5. Adjourn