Last Modified: 2004-01-22
- 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.
| 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 | |
| Sep 03 | Working group last call for spec and CCIDs | |
| Oct 03 | Working group last call on User Guide | |
| Nov 03 | Submit DCCP spec for IESG/IETF review to be Proposed Standard | |
| Nov 03 | Submit DCCP CCIDs for IESG/IETF review to be Proposed Standard | |
| Dec 03 | Submit User Guide for IESG/IETF review to be Informational RFC |
Minutes
Datagram Congestion Control Protocol (dccp) working group
March 4, 2004
IETF-59 Seoul, South Korea
Minutes taken by Ted Faber.
Slides for all talks are available at
http://www.icir.org/kohler/dccp/ietf59
Jabber log is available at
http://www.xmpp.org/ietf-logs/dccp@ietf.xmpp.org/2004-03-03.html
Agenda:
Status & Chair's Remarks (Falk)
Spec Update (Handley)
Summary of mailing list thread on DCCP, real-time, and CBR
(Floyd)
DCCP User Guide update (Phelan)
====================================
Chair's remarks (Aaron Falk)
Since last meeting there has been an energetic discussion of
congestion control versus real-time applications, an update of the
User Guide draft, and a (hopefully) final polish on the DCCP
specification and CCID documents.
The current status of the working group is that the spec and CCIDs
are ready for WGLC (however they require thorough reading since many
editorial changes have been made); the User Guide needs feedback
from the community: is the new direction (describing services as
opposed to APIs) acceptable? useful? Also, there are a handful of
ideas that have come up over the last several months that may be
taken on as new work items.
Before the next IETF, we hope to take the spec and CCIDs to WGLC,
update the User Guide, and update the charter. Here is a proposed
schedule:
- IETF-59: Review Spec, CCID changes
- Mar 04: WGLC for spec, CCIDs
- Apr 04: Publish user-guide-02
- May 04: Revise wg charter
Several possible new charter items have been proposed. They are
listed below with the folks who've agreed to author an initial
draft. (It's necessary to identify an author is before adding
something to the charter.)
- Faster start after idle (Eddie Kohler)
- CCID-3 thin (Eddie Kohler)
- TFRC-PS (Sally Floyd - to be published in tsvwg but will
require a CCID)
- TFRC supporting apps w/limited rate flexibility (mjh)
- 8 packet/RTT initial sending rate (Eddie)
Spec Changes (Mark Handley presenting for Eddie Kohler)
Spec changes include organizational changes and cleanups spotted by
reviewers. Event processing has been clarified. There were many
simplifications discussed at IETF in Minneapolis. The most
significant changes have already been discussed on the mailing
list.
A new state was added, Part Open, to handle a possible deadlock.
Event processing text was made explicit through the use of
pseudocode (much more comprehensive than the state diagram, which is
necessarily incomplete). Text on sequence number validity cleaned
up and ambiguities removed. Changed protocol for Sync packets to
avoid some possible problems. Spec now discusses probabilities of
sequence number collisions for regular and extended number spaces.
Recommend using extended sequence numbers for windows greater than
100 packets. Clarifications added on forward compatibility
including removing the "Ignored" option. Empty Change and Confirm
options added to allow one end to query the option state of the
other.
Open issues status from IETF-58.
- #NDP: removed in favor of NDP count option
- ID and Challenge: removed for Sync and SyncAck
- DataDropped requirements in CCID 3: since the problem is in the
receiver rather than in the network, the draft now suggests
manipulating Xrecv to indirectly limit the transmit rate
Discussion on DataDropped:
- Magnus Westerlund: seems to indicate that this kind of data
drop is not congestion related. The right answer is: do nothing.
- Mark: the options of ignore or treat as network congestion are
both too extreme, this allows a more gentle response.
- Magnus: could this be a valid response for corruption?
- Sally: I believe the text says "drop in receive buffer". You
don't want to send data that you know is going to be dropped.
We think this will also be useful to deal with corruption.
However, using DataDropped for corruption is open issue - this
is a hook for the future.
- Mark: packets are serving no useful purpose, so we felt we
needed to do something, although the response is not as urgent
(as for network congestion).
- Magnus: I suggest adding more drop codes and define these
responses remove special cases.
- Sally: Not something to talk about here. Corruption/
congestion may be uncorrelated, maybe not. Need to think
about that, but this current systems is not a bad start.
Gentle reduction.
- Mark: Yes, this is a placeholder but a reasonable start.
- Colin Perkins: Could use receive window for flow control.
I.e., no receive window, no flow control -- this seems close
to that.
- Mark: have to think about it
- Packet sizes: want to avoid people gaming packet sizes. Not
clear how well this works, added weasel words. implementations
can check. Flag of a possible issue.
- Payload checksum: use SCTP CRC-32c
Discussion on Checksums
- Colin Perkins: I understand why you switched to the CRC-32c
checksum, but I'm concerned that it is expensive in terms of
bandwidth overhead.
- Mark: you don't have to use it.
- Colin: Wireless environments will use it and it's particularly
expensive for them.
- Mark: separate header from rest. OK, that's an issue.
- Colin: You may need 2 types of checksums.
- Mark: Apps which can tolerate loss may not care about
checksum.
- Eddie: It's only 6 bytes overhead.
- Colin: Can be pushed out 8 bytes with padding. Yes? That
would be twice the Internet checksum overhead? It may not be
a problem but we need to be careful.
- Mark: We just can't sort out all these issues before we get
some deployment experience. Go try it. Adding a checksum is
easy.
- Eddie: And you don't have to use it.
- Tom Phelan: The purpose of different checsksums is to provide
different strengths of protection. So, having both use the
Internet checkksum would be redundant (and defeat the intent).
- Mark: Having two coverages does have uses, e.g., to detect
non-congestion errors. You may really want a stronger
checksum, too. Mostly strong checksums are for when there's
no link layer help.
- Tom Phelan: Agree, if you only have one extra checksum, it
*should* be stronger.
- Service Code wildcarding: addressing Bellovin security issue.
Solution was to remove wildcarding.
Discussion on Service Code Wildcarding
- Falk: what flexibility are you giving up by dropping
wildcarding?
- Mark: Nothing useful. A server listening on port w/o
specifying service name now requires service code. A client
cannot specify connection w/o knowing what service is there.
Allowins wildcard was a workarounds because we expected it
would be difficult to get service codes, but we now believe
that getting service codes should be fairly easy so that
should be OK.
- Falk: Suppose I have a client wants to talk Real version or QT
version and a server that will take either.
- Mark: The appropriate service code must be acquired that
out-of-band and that's OK
- Tom Phelan: Adding admin overhead is OK. Since ports added
overhead, so service codes are OK.
- Eddie: Servers can talk multiple protocols and at most service
will fail one to another.
- Colin: One thing vendors will do is mux on the same port.
E.g., muxing RTP and RTCP. What does this buy us? Compared
to potential for abuse.
- Mark: This makes the client's intent much more explicit. It's
important for security to have explicit intent. Therefore,
fewer firewall heuristics are required. This approach allows
fine, detailed description of what is transferred. The
existing port space is insufficient; there aren't enough ports
for fine grained registration. You don't want to put large
numbers in every packet.
- Colin: That seems OK. Although, I'm concerned that people
could lie about Service Codes to get through firewalls.
Having a separate code lets you manipulate server.
- Colin: You can multiplex multiple services on one port.
Horrible, but can do it.
- Mark: Server port irrelevant. It's OK to have many things on
same server port.
- Colin: Doesn't this make the firewall's job harder?
- Mark: No, explicit data makes firewalls easier. They can
specify the specific rules they want (using service codes)
instead of relying on a rough estimate (by using port
numbers).
- Colin: I still don't see the gains, but servers will multiplex
services on same port
- Mark: we just don't agree. Talk later.
- Only trivial changes to CCIDs
Questions?
- James Kempf: Lots of discussion about ID/locator separation at
this IETF. The mobility support in DCCP looks like that stuff.
Are there conflicts??
- Mark: The timing was poor for DCCP mobility support. We don't
know which (or whether any) mobile IP solution will prevail and
so we'll assume they fail. While we hope not, however the DCCP
mobility approach is a lightweight mechanism, so we can
deprecate it if something better comes along.
- James: The DCCP approach doesn't work if both ends are moving.
- Mark: Yes, this is a known shortcoming.
- Magnus: Mobility is a big security hole via sniffing and
stealing.
- Mark: If you are concerned about sniffing, use IPsec.
- Falk: DCCP is only required to be as secure as TCP
- Magnus: I believe the mobility feature should be moved out of
the spec and made an optional extension to avoid the security
hole.
- Mark: Disagree. You can turn mobility support off and it would
be hard to add as an extension.
- Eddie: Agree with Mark.
- James: This is a similar problem to Mobile IP binding update:
there's a protocol in MIP that will avoid a DOS here (lying
about move destination) there may be an IESG issue here (since
it affects multiple protocols). Can this be used to DoS an
innocent 3rd party?
- Mark: Yes. But only if you can snoop nonce exchange
- James: Is the nonce used directly?
- Mark: yes
- Anders Clements: Any thoughts on how to cross NATs?
- Mark: NATs will need to become DCCP-aware. We acknowledge that
this is a long term solution.
- Anders: Is DCCP over UPD to avoid blocking by NATs a crazy idea?
- Mark: Yes
- Colin: Suppose you set up connection to yourself, observe the
nonce exchange, and redirect the stream to some unsuspecting 3rd
party?
- Mark: This may be a problem. I need to think about that.
- Future work
- TFRC for apps that can't directly change sending rate.
- Specs assume that CCIDs assumes data will be sent appropriately
- What about fixed rate or discretely variable rate apps? Try
using TFRC as reference rate and stay within a factor of 2 and
use DCCP as policing mechanism. May be issues when there are
only a few flows. Need some research. Unlikely to be socially
bad, but may not always be fair.
Additional Discussion
- Magnus: How useful is sequence number transition
- Mark: had a fair amount of debate on this. It's preferable to
pick the right sequence number space at the beginning of a
connection. However, flows without knowledge of net conditions
(which includes most flows) would like to be able to switch.
I'm not terribly happy with the current solution but we
couldn't find anything better.
===========================
DCCP issues from mailing list (Sally Floyd)
Some quotes from recent list messages:
- "Real Time apps have no interest in being 'fair'.
- "Don't expect people like XXX to be happy with the 'you must fit
in to TCP's view of the world' when most of their real-time
applications are already being good citizens (by not sending 'all
they can' when they don't have to)." [Referring to a
silence-suppressed, CBR, 4 Mbps video stream!]
- "Maybe some codecs of today, which were designed assuming a QoS
enabled network, cannot make use of TFRC or DCCP."
- "TCP is broken. Nowhere is it written that TCP = best effort."
Background assumptions (ours):
- DCCP and best-effort traffic: DCCP with best-effort service does
not necessarily meet the needs of all apps. In fact, best-effort
service does not necessarily meet the needs of all apps. DCCP is
intended to solve the best-effort problem, not the QoS problem. We
believe that in the long run DCCP offers better performance than
UDP to applications (e.g., ECN, NAT traversal, etc.)
Why do flows have to be bothered with CC? RFC 2914 provides 2
reasons: prevent congestion collapse and share fairly w/TCP. IETF
will not standardize non CC-ed transport protocols.
Why Slow start? CBR app writers don't want slow start after idle
periods or ever. Why?: "We're sending at a low rate so why bother?"
Idle periods: "We're benefiting the network by going idle, why
penalize us by forcing slow start after a quiet period?" "Our
traffic is more financially valuable to ISPs so congestion rules
don't apply" "TCP must be fixed [to be friendlier to CBR apps]"
Current CCID 3 specifies 4 pkts initial window and possibility of 8
small packets in the future. DCCP would drop packets in excess of 4
sent by a CBR application.
As for best-effort traffic with higher initial rates rates? Sally's
view: explicit router feedback is needed. See, e.g., the Quick-Start
expired ID (draft-amit-quick-start-02.txt). You could make this
happen!
Sending rate is limited to grow no faster than doubling in a RTT.
This topic was triggered by mention in user-guide to double your
send rate to avoid TCP from 'stealing' your BW and to avoid slow
start after idle. This suggestion was based on an incorrect
understanding of TCP. TCP's send rate is determined by loss, not by
maximum send rate. Nevertheless, it is recognized that the
doubling-limit poses a constraint for bursty apps, instant-on apps,
and silence suppression. But relaxing this constraint remains a
topic for research.
A connection that has started and gone idle knows a little more about
the network conditions than a brand-new connection. There has been
a proposal sent to the list for a "Faster Start" after idle. The
proposal is for an initial rate of 8 pkts/RTT, followed by
quadrupling of the send rate each RTT until the previous rate is
reached or a drop or a mark are received. This proposal has not
been tested or fully evaluated and needs more investigation.
Implementation experience regarding slow-start problems will help
guide and motivate this work.
Finally, there are concerns about applications with fixed (or very
limited flexibility in) send rates. There is a proposal to allow a
DCCP sender to send up to twice the "allowed" sending rate. To do
this would require a new CCID and further work.
Questions? Comments?
- Wolfgang Beck: SIP has a mechanism to include RSVP. We have
implemented SIP with a probing phase. Would this work for DCCP?
DCCP would signal a reference rate then go on with signaling.
Would this be a solution for initial slow-start as a kind of
reservation?
- Sally: use padded data to build up rate and go? Sounds viable.
- Falk: It seems you could do it w/o SIP or RSVP.
- Mark: Yes, you could use DCCP-Sync pkts to do that.
- Sally: Hmm, would the packet size difference cause a problem?
Slow starting with small packets, then going to large application
packets...
- Magnus: Can you pad an ack?
- Sally: Yes.
==============================
DCCP Users Guide (Tom Phelan)
There's a new revision of User Guide and the big question is what to
do next. The "user" in the user guide is the application. Unlike
the previous version, it is not an API document. Sections include:
- Choosing a CCID
- 2 App stories - streaming media probably not ready
- Shorter section on gaming.
- Stupid DCCP tricks - misc features
- Security section
Controversies in guide (according to Tom)
Fast restart is assumed to be in there.
Training period in strategy 3 - padding the network as discussed before.
- Falk: fast restart is probably not coming anytime soon. Suggest
removing that assumption.
Stream switch
Variable rate media: just can't support rate variations like the
10x difference between I-frames and ??-frames.
- Falk: a sender can smooth these bursty codecs right?
- Tom: you need to ramp up in a frame time
- Falk: I was talking about smoothing the rate variation
- Tom: going from a static frame to a busy frame is a sharp change
- Sally: The fundamental assumption here is that real-time media
users with cheap service use best-effort at the cost of extra
delay, while people willing to pay would not use best-effort.
- Magnus: Can avoid big swings through the right choice of codec,
right?
- Tom: Agrees that most codec can be adapted, but maybe not today's,
especially MPEG-4.
- Mark: There are fundamentally two types of codecs: H.261 and
H.263. One sends close to constant bit rate, in the absence of
drastic content changes. The others have different frame sizes,
e.g., MPEG-4. The latter is not intended for interactive use.
Perhaps the issue we are talking about stems from a mismatch
between codec and application.
- Falk: you said the video is not changing on the smoother codec
- Mark: there are smoothing/quality degradation tricks in the
interactive codecs.
- Tom: There's a similar statement in the user-guide. Your point is
good - some codecs adapt better than others.
- Mark: No - if you want to meet interactive constraints, you need a
codec that produces smooth traffic, or with non-interactive codecs
that use buffering to smooth their output.
Stream padding: always try to send - pad when necessary. removed the
doubling of rate. (This was based on bad assumptions, see Sally's
talk).
TFRC with self-limiting sources. Desperately in need of
simulations.
Restart after idle for games? Will it work?
- Falk: Do we know whether gaming people are using RTP or raw UDP?
- Tom: We don't have much information, but it appears they are using
UDP.
More apps? What's missing?
The section on "Stupid DCCP tricks" discusses specific guidance on
how a DCCP application should use some of the features in DCCP.
- Colin: In my opinion, this version of the User Guide is more
useful.
============================
Closing Discussion
- Colin: Are there any implementations?
- Falk: There are some implementation info on Eddie's page. Not clear
how close they are to the current version of the spec. A fairly
full featured version was developed at ICIR over the summer but the
spec has changed a bit since then.
- Mark: Most implementations are lagging.
- Colin: would like implementations before going to Proposed Standard
- Falk: Implementations are not a requirement for PS (but are a good thing)
- Colin: I still feel we need implementations
============================
CLOSE
|