Current Meeting Report

2.7.21 Datagram Control Protocol (dcp) Bof

Current Meeting Report

DCP BoF Meeting notes

Recorded by Bob Braden on December 11, 2001 at IETF-52,
Salt Lake City Utah
Minor editing by Aaron Falk

The chair Aaron Falk introduced the session (slides)

Mark Handley, one of the DCP document authors, made a brief overview presentation on DCP (slides).

John Lockley(?): The I-D does not give a motivation for DCP or state the problem being solved, as your talk has just done.

Ron ?: The DCP draft lumps too many things together. Suggest that setup, teardown, and DoS security be separated out into separate documents.

Handley: The mechanisms in the document are all closely coupled and are natural components of any transport protocol.

Mankin (AD): A more complete statement of the problem will be needed. We need a new transport protocol because DCP provides a distinctive service.

Handley: Will it be good enough to just extend the document with a writeup of the slides I just presented?

Mankin: No, we will need a more specific statement of requirements.

John Wroclawski: While I am in general sympathy with DCP, I question a number of specific details. It seems to imply that the protocol is not yet fully cooked. For example:

(1) Applying E2E CC (congestion control) at the level of flows is wrong; CC should be applied to sessions.
(2) There are firewall issues. There has to be a control protocol somewhere, but it is not clear that DCP is it.
(3) Your statement that CC requires state is not obvious. See RTP CC concepts.

Joerg: I don't agree that DCP will have a problem with mobility.

Handley: I brought up mobility because it was the only issue that we had not considered at the time of the first BOF.

? Gibson: It is hard to tell from the draft what problem is being solved.

? Sipati (Sun): You claimed that unreliable delivery is needed for performance reasons. Do you have traces that prove this need? [In other words, why not just use TCP?]

Handley: There are many examples where reliable delivery can result in the receiver getting behind. Real video is a common example; over UDP it recovers with some loss of fidelity, but over TCP it simply stops working when retransmissions cause the sender to get too far behind.

Sally Floyd (answer to Wroclawski): The pressing issue is not developing a new E2E CC mechanism; we already have a variety of CC mechanisms. Now we have to figure out how to apply these to unreliable streams.

Michael ? (Cisco): U-SCTP was withdrawn. What is overlap of applications between U-SCTP and DCP? SCTP applications are not necessarily light-weight. We don't want the applications of DCP to overlap with U-SCTP applications, so we don't want DCP to be too heavy-weight.

??: (to Handley): Did you mean that if we use DCP, we can do mobility at a higher layer?

Handley: (response lost)

Wroclawski: The best response to Sally Floyd is to agree. I liked her phrasing of the problem: the goal is to bring our existing CC strategies to bear on this new class of applications. But I still suggest that DCP needs more thinking; it is not fully cooked.

Eddie Kohler: We have been baking for awhile.

??: The name "DCP" is unfortunate because it is hard to distinguish it from "TCP".

Eddie Kohler, another DCP author, presented a brief DCP overview (slides)

Randy Stewart: The CCid=1 case is a hole in the protocol and should be removed. The receiver can use it to simply turn off CC.

Kohler: That's a fair comment.

Randy Stewart: With respect to DoS protection, you don't require an exchange of cookies. Why not simply force a 4WHS?

Kohler: We wanted to allow servers to optionally shorten the hand shake, for example when they are not feeling stressed by an attack.

Handley: The server does not really need to send a cookie. It is required to support it, but server can use it or not.

Wroclawski: "Server" may be a misleading term here.

Kohler: DCP uses the client/server concept only at the very beginning and at the very end of an interaction.

???: For mobility, a nonce can serve as the invariant end point. It makes both mobility and multihoming infinitely simpler.


Casner: Using DCP for RTP would be reasonable, since RTP makes minimal demands on the underlying layer. However, you will need a new version of RT; the current RTP over DCP is not sensible.

For example:
o Might share sequence numbers between RTP' and DCP. Must then share knowledge of sequence numbers between the layers.
o RTCP feedback should be integrated into DCP in some way.
o Time needs serious thought.

Do people want CC for RTP? Many RTP apps don't care about CC, but the network cares. Apps won't care until the network forces them to. We must manage motivation.

Suggests two different protocols, one for unicast and one for multicast.

??: Another need is to drop stale data -- a limited persistence mode.

Mankin: Can handle this in the API without concern for CC.

Wroclawski: three points:
(1) Need functional validation -- need a statement of high-level goals.
(2) Should include necessary functions but don't want to presuppose solution.
(3) Thinking about API should not be deferred until protocol protocol is designed. The mode of interaction should be defined early.

Falk: (2) and (3) are understood.

Floyd: We were thinking about the applications, not about a TCP retrofit.

Casner (to Mankin): The reluctance is partly because media have limited elasticity.

Mankin: That is why we got rid of U-SCTP. A WG should think about CC for layered codecs.

Handley (to Wroclawski): We could think of DCP as a sub-layer of the transport layer. There may be many APIs.

Wroclawski: I agree.

Falk: Does a WG need to consider key exchange protocols?

Mankin: This is very speculative. With JFK, if UDP packets grow larger than MTU, fragmentation results. But you don't want to use TCP because of security concerns.

Mankin: There is an IPR issue: Siemens and Cisco may have IPR claims to related ideas. The IPR claims are with respect to mobility without changing IP address.


A show of hands indicated that the group present felt 1) a problem statement should be developed and 2) the work is worthwhile and a working group should be chartered.


The feedback from the BoF and the mail list will become input for a modified working group charter. Working group charters require approval from the IESG. The draft authors and I will work with the Transport Area Directors to craft a charter that will meet with the IESG's approval. I will keep the mailing list informed as to the progression of our request to create a working group. Comments on these minutes, the DCP protocol or draft charter are continue to be welcome at


None received.