2.7.3 Datagram Congestion Control Protocol (dccp)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional DCCP Web Page

Last Modified: 2005-06-27

Chair(s):

Thomas Phelan <tphelan@sonusnet.com>
Lars Eggert <lars.eggert@netlab.nec.de>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion: dccp@ietf.org
To Subscribe: dccp-request@ietf.org
In Body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/web/dccp/index.html

Description of Working Group:

The Datagram Control Protocol working group is chartered to develop and
standardize the Datagram Congestion Control Protocol (DCCP). DCCP is a
minimal general purpose transport-layer protocol providing only two
core functions:

- the establishment, maintenance and teardown of an unreliable packet
  flow.

- congestion control of that packet flow.

Within the constraints of providing these core functions, DCCP aims to
be a general purpose protocol, minimizing the overhead of packet
header
size or end-node processing as much as possible. Therefore, DCCP is as
simple as possible, and as far as reasonably possible, it should avoid
providing higher-level transport functionality. DCCP will provide a
congestion-controlled, unreliable packet stream, without TCP's
reliability or in-order delivery semantics. Additional unicast,
flow-based application functionality can be layered over DCCP.


SCOPE

Drafts for DCCP, and several associated congestion control IDs, already
exist. The first task before the working group will be an abbreviated
functional requirement validation of those drafts. There are two
possible outcomes:

1) The current DCCP draft is declared suitable for further work, with
  some areas listed for possible extension.

2) The current DCCP draft is declared unsuitable for further work, and
  more formal functional requirement exploration begins.

Prior to the final development of the protocol, the working group will
investigate areas of functionality that should be integrated into DCCP
because they are difficult or impossible to layer above it. These areas
include security and multi-homing/mobility, at a minimum. The protocol
will be for both IPv4 and IPv6. It will not encompass multicast. It
is strictly a unicast transport.

For security, the working group will endeavor to ensure that DCCP
incorporates good non-cryptographic mechanisms that make it resistant
to denial-of-service attacks on DCCP connections and DCCP servers. A
related topic that will be explored is whether DCCP can be a candidate
to replace UDP in the transport of security management protocols such
as IKE and JFK.

The working group will also investigate DCCP's relationship with RTP
(the Real-time Transport Protocol).

Once the DCCP specification has stabilized, the WG will produce a
document providing guidance to potential users of DCCP. The precise
form of this document will be determined by WG discussion, but it
might
include example APIs, an applicability statement, or other forms of
guidance about appropriate usage of DCCP.

Goals and Milestones:

Done  Publish summary of required protocol functions/requirements
Done  Decision to build on proposed DCCP protocol, alternate protocol, or quit and go home
Done  Detailed review of spec and CCIDs
Done  Public design review at IETF meeting
Done  Working group last call for spec and CCIDs
Done  Submit DCCP spec for IESG/IETF review to be Proposed Standard
Done  Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard
Apr 05  Working group last call on User Guide
May 05  Revise charter
Jul 05  Revise user-guide

Internet-Drafts:

  • draft-ietf-dccp-ccid2-10.txt
  • draft-ietf-dccp-problem-01.txt
  • draft-ietf-dccp-ccid3-11.txt
  • draft-ietf-dccp-user-guide-03.txt
  • draft-ietf-dccp-spec-11.txt
  • draft-ietf-dccp-tfrc-voip-02.txt
  • draft-ietf-dccp-tfrc-faster-restart-00.txt
  • draft-ietf-dccp-tfrc-media-00.txt

    No Request For Comments

    Current Meeting Report

    Datagram Congestion Control Protocol WG (dccp)
    THURSDAY, August 4 at 1400-1630

    CHAIRS: Lars Eggert <lars.eggert@netlab.nec.de>
    Tom Phelan <tphelan@sonusnet.com>

    Proceedings by Gorry Fairhurst <gorry@erg.abdn.ac.uk>, edited by Lars Eggert <lars.eggert@netlab.nec.de>.



    I. The agenda was bashed by the chairs.



    II. Status of Internet-Drafts

    The set of drafts below are now done and with the RFC Editor:
    draft-ietf-dccp-spec-11
    draft-ietf-dccp-ccid2-10
    draft-ietf-dccp-ccid3-11

    The following draft is currently in WGLC, see the mailing list:
    draft-ietf-dccp-problem-01

    Several comments have been received - mainly editorial, and wish to pass to IESG after this meeting.

    The WG Chairs also made a call for comments on the Problem Statement from the meeting room. No comments were received, except from the AD:

    Allison Mankin: The document mentions SIP. This is a protocol that needs congestion control, which is not what it says in the draft. The text should be changed (it could omit SIP from the list of things that do not need congestion control.

    The authors agreed to revise the document, incorporating this and other comments previously received on the mailing list. The revision will conclude WGLC and the revision will be forwarded to the IESG.



    III. Proposed New Milestones

    The chairs proposed these new milestones:

    WGLC by November 2005
    draft-ietf-dccp-problem-xx
    draft-ietf-dccp-tfrc-media-xx

    WGLC by March 2006
    draft-ietf-dccp-user-guide-xx
    draft-ietf-dccp-tfrc-voip-xx
    draft-ietf-dccp-tfrc-faster-restart-xx

    It is planned to update the User Guide based on implementation experience,
    implementors please do contribute.

    After additional feedback from Sally Floyd and Allison Mankin (AD), the milestones were revised to:

    Complete WGLC by November 2005
    draft-ietf-dccp-problem-xx
    draft-ietf-dccp-tfrc-media-xx

    Complete WGLC by June 2006
    draft-ietf-dccp-user-guide-xx
    draft-ietf-dccp-tfrc-voip-xx
    draft-ietf-dccp-tfrc-faster-restart-xx

    The chairs will circulate this proposal on the mailing list and initiate the milestones update process, assuming the WG agrees.



    IV. Status of Pre-WGLC Drafts

    Two presentations from Tom Phelan on draft-ietf-dccp-tfrc-media-00 and draft-ietf-dccp-user-guide-03.

    The history is that the User Guide needed to be separated from this text. The work evolved at each stage. The next step is to incorporate all comments sent to the list.

    Colin Perkins: This draft is coming along - but clearly says that DCCP does not work for several classes of applications. Given we have just published a new RFC on the standards track, should these classes be removed or addressed?

    Tom Phelan: I do not know what to do to make it work in these cases.

    Colin Perkins: The document is valuable where it says what works. My concerns are with describing what does not work.

    Sally Floyd: There are things that do not work (e.g., a 10 times increase in video flow bandwidth - this is broken). My conjecture is that there is no answer for this without QoS.

    Colin Perkins: I largely agree with this, we don't know how applications may change (codecs, etc.), experiments are needed.

    Sally Floyd: I agree.

    Lars Eggert: Should we propose to split the draft?

    Jim ?: This draft tries to complicate a really complex problem. There is complexity within each of the two spaces application and media. How can we make an informed decision about what you wish to control?

    Tom Phelan: Yes, that is fair. TCP, TFRC deal with different application impact when faced with congestion: Data applications brown-out; media applications black-out.

    Jim ?: You can do something that is counter-productive to an application. How can you make an informed decision and know that you are not doing more harm than good?

    Ted Faber: Looking for general descriptions of fairness is hard, and not the right way.

    Mark Watson: We need to examine fairness on different timescales. Users may be happier to know a system cannot deliver, rather than to brown-out.

    Ted Faber: Generalisations are tough. You are never just looking at an instant in time (single packet). Multiple time-scales need to be understood.

    Bob Briscoe: You need to describe applicability, you should not be silent on this.

    Tom Phelan: We need to discuss what it says in the draft - the truth is important.

    Colin Perkins: There is a difference between saying what works, and what is for further study.

    Lars Eggert: We don't seem ready to call this. We need more on the third class of applications. If we remove class, is the document still useful?

    Colin Perkins: Yes - This addresses some of the critics, but you can say there are difficulties.

    Sally Floyd: We can seperate things: This we can do; This we don't know how to do now (current research); This we do not expect ever to do.

    Mark Handley: We should say more about these things that we know will need more work.



    V. Sally Floyd: draft-ietf-dccp-tfrc-voip-02

    Possible revision to CCID3.

    <slides>

    Mark Handley: TFRC does not say anything about whether the units of measure are packets per second (pps) or Bytes/s, because TFRC actually assumes fixed size packets.

    Sally Floyd: OK. TFRC says there will be a future draft describing TFRC with a variable packet size, but this has not been published.

    Bob Briscoe: There is a difference between TCP and TFRC behaviour. For TCP, multiple losses on one round trip time do not matter, with TFRC it does.

    Sally Floyd: Yes I agree.

    Mark Handley: How does a small size TCP packet size compare with the performance for *byte* loss. TCP would have been better with small packets?

    Sally Floyd: Yes.

    Mark Handley: So what does "fairness" mean?

    Tom Phelan: When we talk of packet size, we are breaking the rules for TFRC in comparing different sizes?

    Sally Floyd: Should we ditch VoIP mode. Which is better for applications?

    Mark Watson: What does *bye* loss mean?

    Sally Floyd: If a single byte from a packet is counted as "lost", then the whole packet is dropped.

    Mark Watson: Is this realistic?

    Sally Floyd: Behaviour is similar to a drop-tail queue in bytes, or a RED byte-mode implementation.

    Mark Watson: Is this an incentive for applications to use smaller packets?

    Sally Floyd: ... People who like RED in byte mode, have suggested this is an incentive for people to use large packets.

    Allison Mankin: The results are not fair in a high loss regime, compared to a TCP flow - was it greed? or a concern about something else?

    Sally Floyd: In 40-50% mode the equation does not perfectly collect TCP behaviour. The equation could be tweaked.

    Allison Mankin: Is this so for both for TFRC and TFRC-VoIP?

    Sally Floyd: Yes.

    Allison Mankin: It would be nice to analyse the actual performance. Can you actually run voice over it?

    Sally Floyd: I was not planning this.

    Allison Mankin: This may show something on balance about this, considering the user performance. There could be interesting results if you use specific codecs. It's a good question.

    Sally Floyd: The jury is out for what is best for the VoIP people.

    Allison Mankin: I propose a test experiment as a trade-off test when we ask transport questions...

    Mark Handley: When we talk about small packets, do we have the right comparison? TCP performance differs by packet size. Should we compare TFRC with optimal-sized TCP packets? We don't have the answers yet.

    Colin Perkins: Interactive applications may need small packets for various reasons, including packetisation time.

    Sally Floyd: There are open issues. (1) Is it ok to have congestion control for small packet flows that receive much more bandwidth than large-packet TCP flows in environments, where small packets are less likely to be dropped than large ones? (2) Real-world experiments to explore relative packet drop rates for large-packet and small-packet flows. E.g. using Ping, or TCP, with data packets of 20, 200, 512, and 1460 bytes. (3) Explore VoIP TFRC in environments with mostly small-packet traffic. People who are interested in such real-world experiments, please contact Sally Floyd.

    Ted Faber: Does NS2 keep the TCP cwnd in bytes or packets?

    Sally Floyd: I used one-way TCP, this is in bytes.

    Tom Phelan: What do we do next?

    Sally Floyd: We keep the draft as it is for a few more months and do some work and then decide.

    Tom Phelan: The technical solution seems to be stable (to authors) - so the I-D could become experimental.

    Sally Floyd: I would like to re-discuss the status in March, and see what to do then.



    VI. Sally Floyd: draft-ietf-dccp-tfrc-faster-restart-00

    This I-D is a pure paper proposal, work needs to be done. The motivation is to allow applications to more quickly restore an older sending rate after an idle period. Some email also asked about what you do if it was the application that limited the rate?

    Mark Allman via Jabber: Is the tfrc-faster-restart also valid for a TCP idle restart?

    Sally Floyd: ... It may be that you can only be more agressive with TFRC with a low-rate (i.e. capped) for a specific profile of use. If it were not capped, then it may be OK for TCP?

    Allison Mankin: People measure skype and that doesn't seem to bother with Comfort Noise, CN.

    Sally Floyd: That's why application-limited cases are important.

    Mark Handley: Note RFC2851 describes TCP cwnd validation and is Experimental.

    Allison Mankin: Since performance depends on various things and also people's choice, implementation parameters need to be chosen, rather than fixed.

    Tom Phelan: Implementations vary. Some implementations turn-off the flow during silence (send nothing), some transmit CN, some transmit CN once and then use the same CN for as long as is needed.

    Tom Phelan: I can speak for Sonet Networks, many users use silence suppression and a good proportion do not.

    Colin Perkins: It's not just simple case, we need to also consider Multipoint Control Units (MCUs).



    VII. Issues with Interactive Applications Using DCCP

    Alan Smith: draft-burness-dccp-interactive-apps-00

    Sally Floyd: A question was asked in evaluation of the CCIDs to see if there was sometimes an advantage in changing between CCIDs. Is this "playing" of concern?

    Bob Briscoe: People who build a system, don't necessarily do what was written in the RFC.

    Aaron Falk: The spec does say something on this.

    Tom Phelan: If you have a CCID geared to an application, can another application mis-use this?

    Sally Floyd: You do not do that.

    Allison Mankin: I'd like to see a study - do real player competition experiments to see what the real impact is.

    Sally Floyd: There are papers that reverse-engineer real player.

    Allison Mankin: Experiments can give us a baseline that will let us understand escalating capacity usage.

    Sally Floyd: There are also other players. In actual networks UDP is currently a minority (<10%). If I were an ISP (I am not) and I saw increasing UDP traffic, I'd configure preferential discard of traffic with UDP.

    Bob Briscoe: Discarding on packet protocol fields is not always useful - something sent on a TCP protocol value is not necessarily what it says it is...

    Sally Floyd: Most TCP, is actually TCP.

    Bob Briscoe: .. but this policy would give a wrong incentive for people to lie about the protocol type, and we'd need to then work on that problem. We say 4x400ms in this presentation, because after an idle time it is not the client's PRTT that matters, but the average RTT over the path.

    Sally Floyd: This is true, but work is needed on the value to be used. How to do congestion management for real-time interactive applications such as telephony and video-conferencing?

    Alan Smith: (...) As mentioned that congestion manager had benefits for DCCP.

    Sally Floyd: The Congestion Manager was mentioned in the spec, but as far as we know, has not been implemented.

    WG Chair: We like the discussion in this I-D, we should talk next time about
    the position with respect to this charter.



    VIII. Implementation status

    <slides>

    WG Chair: There is some inter-breeding between the various threads of implementations and the level of implementation varies against the spec.

    Aaron Falk: Are these implementations against the full spec?

    Tom Phelan: These too (some others) are trying to remain active and implement the spec.

    Mark Handley: UCL is planning an implementation too.

    WG Chair: Should we have a bake-off sometime? Most people don't go to IETF?

    Colin Perkins: We have a lot of implementations starting to happen, can they come up with a common API proposal?

    Allison Mankin: We can document APIs as Informational. You could think about this as a rechartering thoughs.



    IX. Discussion on Future Work

    <slides>

    Bob Briscoe: Do you mean mobility in the slides?

    Tom Phelan: I was thinking of mobility.

    Allison Mankin: Places where you can change addresses - this part was taken out, because there were implications on how you prove movements are authentic (without cryptography)

    Allison Mankin: I would hesitate on mobility, we also have HIP.

    Allison Mankin: The slides suggest a MIB, and MIB doctor cycles are slow, is there a pressing need for this yet?

    < There does not seem to be much interest >

    Allison Mankin: The Datagram TLS spec is now out - has this applicability? Eric Rescorla is willing to do this, is there interest to work with him?

    Aaron Falk: When we chartered the WG, this was a notional API giving semantics for the upper layer. We may need to say more about how this communication proceeds. Is there energy here?

    Sally Floyd: My inclination is for a problem Statement for CCID Interactive Media (rather than a requirements document). To identify issues that we don't have answers for yet.

    Mark Handley: There is a proposed IRTF research group in this area, which may discuss research issues that can be done there. We don't wish to stall this work in DCCP. I think the research group (if/when formed) would really benefit from inputs from this WG with real experience. Actual generation of the CCID is IETF work.

    Colin Perkins: I agree with Sally. Another question: do we need to write-up the
    interface to RTP?

    Tom Phelan: Yes.

    Tom Phelan: There are signs of a change in the WG from a development of DCCP to a user of DCCP.

    Lars Eggert: Please write I-Ds (may be short) on anything of interest to this group to allow us to discuss these in Vancouver.

    Slides

    DCCP WG Meeting Agenda
    Streaming Media and TFRC
    TFRC for Voice: the VoIP Variant
    Faster Restart for TCP Friendly Rate Control (TFRC)
    (Issues with) Interactive Applications Using DCCP