Datagram Congestion Control Protocol Working Group
November 10, 2004
Meeting notes taken by Ted Faber
- WG status (Aaron Falk)
- Comments on spec from working group last call (Eddie Kohler)
- Comments on CCID2,3 from working group last call (Sally Floyd)
- Discussion of VoIP & TFRC (Tom Phelan, Sally Floyd)
WG STATUS, Aaron Falk
- WG last call for spec CCID[1 & 2]. Some bugs and nits - Eddie will
cover. Drafts will be recycled then week long review after.
- New milestones - User Guide, Charter revision in Spring
- VoIP Tom Phelan's VoIP fairness issues resulting in Sally Floyd's
- Possible new work items:
VoIP mode for CCID3
Recommendations on padding (user guide)
- Allison Mankin: it probably makes sense to have the TFRC
discussions here. However we have to make sure the right people
- Eddie Kohler: should we make CCID3-thin a possible work item?
- Tom Phelan: CCID3-thin was a really a thought exercise for VoIP.
With the discussions on TFRC, we put it off.
- Aaron: Hmm. Should we combine CCID3-thin with CCID3-VoIP?
- Tom: an interesting idea, need to think about it.
"REVENGE OF THE DCCP SPEC", Eddie Kohler
- Header Rearrangement.
Switch location of type/extra seqno bits. Suggestions from last
call: remove 24-bit seqnos; there is too much reserved space.
Assessment: No clear gains in space compression from alternate
header designs see list.
An alternate header: remove 16 bits of reserved space by letting
options start mid-word. Out of conservatism, recommend against
- Feature Negotiation.
Clear up allowing preference changes during negotiation. Removed
out-of-band feature negotiation due to security implications.
- Congestion control
- Eliminated CCID1 - "unknown CC". Hard to justify, especially
since it would not work for any existing CCID.
- When is a packet "acknowlegable"? Made clear definition.
- Should ECN be mandatory? (from Perkins) ECN is default and
encourage ECN. Not mandatory.
- Define CCID requirements (from Perkins).
- Remove Reset Congestion state option
- Make clear that Data Dropped state is reliable (from Falk)
- CCIDs must have ack-based cc
- Packet exchange
SHOULD report 0-length data/data ack packets to app. (This is a
compromise from Perkins:MUST, Minshall:nothing.) DCCP Resets have
options processed. Error in option processing can cause Reset to
be sent in response to a bad reset. Timers and backoff rates more
explicitly defined Comments added to pseudo code - weirdness
- Ignoring options on Data
This fixes a DoS vulnerability from, e.g., an attacker sending
mandatory options which are not understood by a receiver.
Solution: mark options that change state of connection and say
these MUST be ignored on DCCP data. (one small exception)
Ted Faber: suggest including reasoning for this change in the
Changed analysis in Security Considerations section to describing
the number of packets required to achieve 50% attack success.
Brian Rosen: think about avoiding data injection attack - at
least be concerned about data injection. A particularly
annoying attack in multimedia is one where the attacker injects
a single packet into a stream with profanity.
Eddie: battling data injection attacks is all about header space
tradeoffs. If you use long seqnos, you can avoid the problem.
Also some apps can deal with corruption. No way to make it
Handley: The application designer is the only one who knows
whether they are more sensitive to header overhead or to data
injection attacks. So, it should really be up to them to chose
large or small seqno space.
Colin Perkins: The spec needs to include some rationale to
inform application designers.
Eddie: already there.
Allman: Will app writer be able to understand and make informed
Handley: The spec not place for educating app writers, it is
read by implementors. The API is where one puts information for
- Miscellaneous changes
Default RTT to 0.2s. Rather have default timers too long than too
short. Checksum coverage tweaked. Define units for timestamps -
10 ms units and elapsed times - and allow multiple timestamp
echoes. Path MTU section rewritten collect what packets may be
sent unfragmentable. Updated IANA considerations section. Max
Open Q's (No consensus):
- Should not claim to be suitable for interactive voice, seems to be
- Specify ICMP interactions. Haven't done it. Reference TCP??
- Eddie wants to leave undone:
* List of Service Codes
* Provide sample implementation of Init Cookie
* Make a short glossary
* Multiple service codes per port considered harmful (Not what
users expect - more than one app listening per port?)
Colin Perkins: sysadmins will say "you do what??"
Allison: SCTP does this, so sysadmins understand this. If
*Bellovin* says it's OK, that's a strong endorsement.
Colin: This is not my experience
Handley: The intention of 'service codes' is to increase the
flexibility of firewalls beyond port-based rules
Eddie: Not all spec authors agree with Mark H.
Colin: Training and confusion
Randall Stewart: Firewall guys only look at ports in my
Eddie: Expect firewall rules to port filter
* Aggression Penalty reset considered harmful. Consider data
injection in this. Discourage this, but bring out the issues.
Aaron: An additional question I raised on the list: IPSec SPD
proto/port #. Does this imply a change IPSec implementations or
spec? Will someone carry this to them?
Allison Mankin: IPSec almost never use ports. Feature exists,
Aaron: Did SCTP have problems with this?
Allison: SCTP multihoming issues made this big draft
Handley: Service codes do not affect IPsec. Flow association is
done the same way using SPI and IP addresses.
Colin: You mean 2 application on same port?
Eddie: You can do this with TCP. Service codes restrict what
TCP might do added info for firewalls. May not go to a
Handley-service code only world.
Aaron: what about traffic inside a tunnel??
Colin: IPSec needs to be aware of service codes.
Allison: I don't think you're adding anything new.
Colin: Don't know enough to comment on IPSec
Aaron: (summarizing) It appears that there no implications for
IPSec protocol changes driven by DCCP. There may be
implementation changes to support a new protocol (since SPDs
index based on protocol (and IP address, port number).
LAST CALL COMMENTS ON CCID2, Sally Floyd
- Status: main feedback from Mark Allman, Aaron Falk. No open
questions. Several clarifications summarized below.
- Byte Counting - Why include it? Is only at Experimental for TCP.
A minimal version of byte counting, recommended by Mark Allman,
will go into the revision.
- Ack ratio - rapidly changing cwnd can cause much feature
negotiating during congestion on forward path. Spec now restricts
re-negotiations to once per RTT.
- Q: Why at most 1 RTT sample per RTT? Added clarifying text to
- Changed minimum for sshthresh from 2 to 1. (Probably doesn't make
- ECN - Specify that congestion window increased only for non-ECN
- Initial CWND: Clarified that the exact rules if RFC3390 apply.
- CCID 2 masquerading as CCID1. Killed CCID1, so this is a
LAST CALL COMMENTS ON CCID3, Sally Floyd
- Feedback from Falk, Allman, Pengfei Di, Ladan Gharai, David Vos
- CCID3 spec difficult to read. Revised to include more text from
RFC34448 but did not do complete rewrite.
- Why so many ways to convey loss: Ack Vectors, Loss Intervals, and
ECN. If only one way could be provided, it would be Ack Vectors.
Loss Interval method is for senders that want to offload work to
receiver. If ECN is not used Loss Event Rate is sufficient and
still more work is done by the server.
Eddie: agree that we need all three. Should we require loss
intervals in all cases?
- Always send loss intervals is mandatory and the other 2 methods
are optional. Claiming no-ECN makes easier for receiver, note
that this is a negative incentive for ECN.
Sally: Prefer either AV or LI, but not strongly; would not
oppose LI mandatory
Tom Phelan: Don't like AV because it looks too much like
Colin Perkins: AVs are big. Please don't make them mandatory.
Sally: now LIs are mandatory, end of discussion here. Continue
on the list.
- Potential Changes moved to appendix
* initial sending rate increase to more than 4 pkt/RTT?
* < 1 ACK/packet when data rate is less than 1 pkt/RTT?
* more than doubling the sending rate from one RTT to the next?
* faster restart after an idle period?
- Clarified a limitation on RTT computation
- Some Loss Interval clarifications. Add initial rate based on
RFC3390. What does the Loss Event Rate Option report when the
loss event rate is zero? Clarifies that ECN either use AV or LI,
now changed to must use LI.
Aaron: another revision forthcoming?
Sally: yes, number changes and stuff we've talked about today.
Eddie: would like more feedback on readability.
Sally: if there's more rewriting, Eddie will do it. :-)
TFRC SELF-LIMITING TFRC SOURCES, Tom Phelan
- File transfer type applications are greedy/VoIP sources aren't.
- Simulate G711 VoIP. Sim details on slides. 96Kbps sources
- Dumbell topology
- Chokepoints 1.5 Mb/s 256Kb/s 45 Mb/s
- 1 TCP/ 1TFRC 1.5 Mb/s looks OK.
- 6TCP /1TFRC Fair share 214K TFRC driven down to 20Kb/s (!) CBR
w/o TFRC flow loses packets, but throughput is OK.
- Packet rate vs. Byte rate (Dado Colussi analysis) TFRC gives a
packet rate - in terms of packet rates the earlier sims are
getting their fair share of *packets*
- VoIP mode for TFRC. Special dispensation for small flows and bps
- New ns gives some differences!?
Aaron: I can't tell from the graphs whether this is adequate
quality at the receiver or not. Are you under-running the playout
Tom: tough to tell
Sally: updated some defaults in NS which may explain this
Steve Casner: what's the delay
Eddie: spikes would cause loss in CBR, too.
Tom: existing systems do work
Handley: if TFRC is sending smooth and the link is inducing
burstiness have to smooth it out. Otherwise, you are evaluating
the quality of the link conditions, not the congestion control
Aaron: Perhaps you need to measure at sender side to avoid
interference by the link conditions.
Sally: do you see this much burstiness because of the reverse
Tom: bursts are there with or without reverse path traffic.
Brian Rosen: Is DCCP/TFRC inappropriate for any application?
Tom: Streaming video should work, but not streaming audio packet
size at issue
Mangus Westerlund: packetization is the issue
Handley: streaming audio should use big packets for header
Eddie: non-real-time streaming audio makes big packets
Colin: buffering latency is an issue - more buffering makes life
easy. Can't say DCCP/TFRC is unacceptable for all applications
Tom: link delays are a big deal for real-time apps, drives need
for small packets.
Stefan Weger: video has variable packet sizes - how does that
affect this analysis? (Stuff a frame into as few packets as you
Westerlund: buffering modeling needs to be looked at.
- DCCP user guide impact. VoIP mode will need to be added and w/o
VoIP mode, no guide. :-)
Tom: wait for VoIP?
Aaron: are there common parts of the User Guide that can move
forward without the VoIP issue resolved?
Eddie: Dunno how long VoIP will take, but prefer one document
Eddie: a lot of strategies will be for interactive applications
Aaron: so, is there only 1 profile of interest??
Eddie: There are some things (API) but TFRC problems dominate document
Aaron: packet size stuff seems to dominate
Aaron: not a lot of help for Tom. Interest level? Nothing to say?
We need to give advice (the protocol has lots of knobs) and need
the User Guide to convey that. What goes into the document should
come from application community, e.g., AVT folks.
Colin: Might want to start from where we know it works.
Aaron: for example?
Colin: Streaming video.
Brian Rosen: No evidence that DCCP works! Don't think so, but
certainly no evidence.
Eddie: I agree wrt the user guide. Point of user guide is to
describe use. No demonstrated use, tough to write a guide. Also,
there isn't a massive universe of implementers waiting for the
guide. Sorry it seems to be languishing, but I think this is the
Colin: need to talk about working cases. If none exist -> short
Tom: API view or users' view...
Aaron (summarizing): focus now on getting VoIP working and think
of the Users' Guide as a place to document what we discover works.
Tom: I'm in general agreement. I can publish a simple revision
to keep it the draft in the repository.
Colin: There are easier cases than VoIP. Demonstrating one would
Brian Rosen: Want to see it work.
Aaron: implementation proof not a requirement for working on the
Stewart: I note that there is DCCP code in FreeBSD Kame? Does it
work? If so run it. Easy to do simple tests if the code works.
Colin: Some people adapting media tools to be congestion aware
Allison: VoIP is rolling along w/o congestion control. Lots in
play. Also, IP video is a good spot for potential DCCP use.
Voice is not the big issue. Creation of a DCCP standard may drive
Colin: DCCP can't be worse than TCP video streaming.
Tom: sim 1-way media
Handley: DCCP is red herring - congestion control is at issue.
This working group can't cover the whole space, but there is
plenty of prior work in applying CC to multimedia congestion
control. No one believes that DCCP solves it all. Lots of this
stuff is off topic.
Rosen: Interactive video unlikely to work. DCCP is solution w/o
Aaron: I don't think you are hearing what Mark just said. He
said there *is* prior work and that there are some other
applications for DDCP.
Brian: I have never seen an implementation of CC for streaming
media that works.
Tom: I haven't either.
Eddie: DCCP is not the streaming media congestion protocol.
DCCP is a thing that *might not* help anything, but I believe it
will. Started from abstractions to protocol is interesting and
I think useful.
Colin: (Again,) consider radio streams over HTTP. I think that
the CCIDs in DCCP are at least as good.
Sally: agree with Colin. I think that CCIDs work for streaming
recorded stuff. Exploring new things. No one MUST use DCCP.
Mangus Westerlund: I have implemented slow switching of media.
Have to adapt media to available bandwidth.
Handley: different application - Radio astronomers. Send big
data - no reliability, but don't kill the network.
Aaron: Please writeup something about this application and
send to list.
VARIANT OF TFRC FOR VOICE, Sally Floyd
- NB small packet TFRC was an open issue in the TFRC spec
- Issues for VoIP traffic
* Small packets - fairness in pps does not result in fairness in
* Measuring Congestion - packet loss vs. loss event rates
* Faster restart after idle
- VoIP: fairness in Bps. TFRC gens packets/sec. VoIP mode gives
b/s with TCP flows having 1500 packet/sec. There is an optimistic
assumption buried here that network will continue to be limited in
bps not pps, this may change. (At most 1 pkt/10 ms.)
Colin: some people doing this at 5ms packets
Sally: might not want to support that. Good to know.
Sally: might want to go to a private net, too
Tom: Who's doing this?
Calculate the TCP rate from the TFRC equation with 1460 bytes and
adjust for VoIP headers (40 bytes) (we know it's an
approximation). Minimum interpacket time is 10 ms. Doesn't
restrict anyone Want to give an incentive to not have
unnecessarily small packets. Generally will have to eat the 10 ms
Aaron: can you use the actual header size?
Sally: if you know it.
Casner: strict interval? Average?
Sally: I wrote strict min, could be persuaded to get average.
Tom: skew in the network means that to hit 10ms interpacket time,
one will have to use longer.
Sally: thanks for pointing this out. I'll change it to 9ms min
interpacket time to allow for a nominal 10ms and with some
margin for skew.
- Slide of sims, that show basic good results
Colin: talking about packet sizes?
- Congestion indication
VoIP uses loss event as congestion indication. NB this is packet
loss rate. Packet size and sending rate && burstiness affect this
rate. Small packets seem to be less likely to be lost than large
packets. Many variations. Lots to look at.
Colin: Sims use very large packets. Recommend using 30 payload
bytes per packet.
Sally: I used Tom's 120Bpp.
- Fast restart after idle:
Sender knows more when restarting than when starting. Never
reduce the sending rate below initial window. Quadruple up to old
sending rate after restart. Sally's opinion clearly fine for VoIP
or other flows w/constrained sending rate.
- May want to split these two ideas into separate tracks/documents.
- The next step: Allow TFRC to send more than twice the reported
receive rate if allowed by send rate, rate has been sustained in
the past no congestion in the recent past. Justification: some
- Current NS-2 code has the VoIP variant and RFC3390 initial sending
rate. A few more updates are needed: add RFC3390 sending rates
after idle; faster restart; overhead for packet headers.
Sally: Want to allow padding when changing video rate, but there
are probably constraints to keep padding low. The padding is used
to probe for available network bandwidth before making a codec
Aaron: This is open issue. Talk.
Mark Allman: if you are adding fast restart, should you also
consider faster slowdown?
Eddie: pseudo code in draft. Check it out.
Dado: how do you want to change TFRC response function?
Sally: TFRC is very optimistic in several cases. Not much more
aggressive than most aggressive TCP. Current response function
may be OK.
CLOSEOUT, Aaron Falk
- We've last called spec && CCIDs
- Next is to checks the revisions of the drafts
- New work items:
* something about mobility
* updating TFRC with VoIP mods
Allison: suggest sending drafts to AD review and make final fixes
there. Then IETF last call.
Aaron: We still need a 1 week review period for the working group to