DCCP Minutes, IETF-62
Datagram Congestion Control Protocol WG (dccp)
Monday, March 7 at 1300-1500
CHAIR: Aaron Falk (email@example.com)
- Agenda Bashing
- WG Status, Aaron Falk
- Review of IETF Last Call/IESG review comments on DCCP spec, CCID2,
CCID3, Aaron Falk
- Planned non-editorial changes to spec, ccid, Eddie Kohler
- DCCP User Guide update, Tom Phelan
- TFRC for Voice over IP, Sally Floyd
- Presentation on Rate-Adaptive Voice Codecs,
Note: the meeting is being unicast streamed
Aaron Falk (AF) spoke about general status. The milestones were
reviewed. The WG has completed the DCCP specs and CCIDs. He asked
what the future direction would be, now that the core work was done
(this was not discussed, since there was no time left at the end of
DCCP Spec has passed IESG review with small changes.
The DCCP user guide is still not complete. This may be too early to
publish. We need implementations and feedback to drive the guide
document and also get contributions to this document.
Note that VoIP mode for TFRC is not yet converged - there are still
things to be changed and updated. Sally will present results later,
feedback awaited from the AVT community (not necessarily today).
Collin Perkins (CP): There could be feedback on VoIP mode on
Wednesday in the AVT WG.
Sally accepts the invitation to talk in the AVT WG.
AF: Could you also encourage the AVT list members to review the documents
and give feedback to DCCP? We should not prejudge what is (not)
acceptable for AVT.
Allison Mankin (AM) (AD for DCCP): There is not so much
communication between the two communities as I would have
liked. There are other documents that speak about Congestion Control
(CC), the H.264 spec (RFC 3984) says a lot about congestion control
- but was not (as far as I know) reviewed by the CC folks in the
IETF (due to time constraints). Please be aware of the need for
CP: The codec supports various rates - but these are not explicit CC
functions. There is no CC work in AVT. We can send pointers.
REVIEW OF IETF LAST CALL/IESG REVIEW COMMENTS ON DCCP, Aaron Falk
The list of Last Call comments on the DCCP Spec is available at the
ID-Tracker. The comments from the IESG were reviewed.
One of the comments related to the procedure for defining extensions
to CCIDs. What does this mean?
AM: (expanding on her tracker comments) It means that if you do an
experimental CCID, then you can do experimental extensions. If a
CCID is Standards Track - do not add IANA allocations to add
experimental features. If you need to do experimental work, just
do the work in the lab using the experimental allocation of
numbers. When you're ready, you can go and get a standards track
document created. This separation means the CC Standards Track
RFCs are well understood.
Eddie Kohler (EK): This makes me think this is the right thing.
But, TCP was extended experimentally a number of times...
AM: If we do experimental work we need to make a whole CCID
algorithm experimental. TCP is different and harder to
modularise. Standards Track DCCP CCIDs are a module, which must be
a standard. A "flakey" new module is a different CCID.
EK: As long as this is an understood change of practice, I am
The text needs to say that new protocol extensions must go through
IESG review, but need not be standards track. Transport protocols
require tight control of extensions to CC methods. Why?
AM: This makes sure that the extension MUST be an IETF document,
not one from other standards bodies.
EK: But the spec quoted RFC2434.
AM: In that case, the text must be correct. However, we must fix
the potential loop-hole. Note "approved by the IETF" is not the
same as "reviewed by the IESG". This is protection against folks
outside the IETF extending DCCP in unsafe ways.
PLANNED NON-EDITORIAL CHANGES TO DCCP SPEC and CCIDS, Eddie Kohler
Eddie presented a set of changes including:
Extra options with invalid lengths are ignored s/invalid/nonsensical/
48-bit sequence numbers
Loophole on CC could cheat by repeated changing of CCID.
Receiver rate change.
Timespan measurement units.
CCID2 and CCID3 also have minor changes.
Eddie promised to post the changes to the list.
DCCP USER GUIDE UPDATE, Tom Phelan
Tom talked about the current content, the API-centric approach and the
options. He asked what should be done to make this go forward? There
are issues with completing the document given the current lack of
deployment and the need for applications expertise.
EK: I like the user guide, but... the important thing is that the
document should be kept alive, pending implementation or
AF: The "DCCP Problem Statement" ID had a similar role, in that it
was written as a tool for discussion, then frozen.
EK: The Problem Statement ID died. It was not published. The User
Guide needs to be published.
AF: The Problem Statement could still be published (and people do
want to understand where the decisions came from).
Sally Floyd (SF): Publication of the Problem Statement would be
good. I will help publish.
AF: I will take this up with Allison (DCCP's responsible Area
TP: The current document will be updated and I will issue rev -04.
AM: Is there some material that is current and could be ready to
publish? Then we could take the User Guide as a later, more
detailed, document that could be published? What would an
appropriate title be?
AF: "Application concerns about DCCP" perhaps?
TP: Splitting out these concerns could be done pretty easily.
AF: I'll take this as an action. Tom can you make a sample abstract
for the new document and send it to the DCCP list.
TP: Yes. I'll also refresh the User Guide draft to keep it alive.
TFRC FOR VOICE OVER IP, Sally Floyd
draft-ietf-dccp-tfrc-voip-01.txt (not in ID archive at the time of
Sally reviewed her previous talk (TFRC with a basis of byte/sec rather
than pps). TFRC assumes a packet size of 1460B. The VoIP change takes
into account protocol headers for small packets and specifies a
minimum interval between packets. There was some work still to be
evaluated, which appeared in -01 of the draft.
She discussed simulation results, and noted that at very high
congestion, a VoIP flow receives more capacity than TCP. This is
because TCP can not send multiple packets per RTT in high congestion,
but TFRC can send many small packets in one RTT. Should we use a new
method for processing loss events at high rates of loss?
Modified results were presented describing a small packet mode. There
are still issues - do networks behave differently with small packet
congestion and does this have an impact? There were many router
behviours. It may be easier for a router buffer queue to hold a small
packet, alternatively packet buffers may be large and queuing may be
irrespective of packet size, routers could do byte counting and that
may set which packets are dropped. There are many combinations and
If Active Queue Management (AQM) in byte mode, then the modified TFRC still
gets much more of its share.
AF: Is that result independent of TFRC?
SF: Yes - but 2 big packets could become 30 packets in TFRC.
AF: That's because of the packet size?
EK: What about a TFRC that is not in VoIP mode, that uses small
EK: What's the order which is worst (TCP, TFRC, TFRC-VoIP)?
SF: We assume a transport protocol does not know what routers are
doing. So we can't assume packets are dropped due to pps / bytes
sent, drop rate not necessarily and indication of level of
The TFRC-VoIP mode ID should be stable by the next IETF.
Collin Perkins (CP): So this looks like a reasonable thing to
do... But, let's not call this VoIP, because it does not solve all the
problems for VoIP.
SF: Call it "Small-packet mode"?
AF: We started this work to solve VoIP mode.
CP: It does help VoIP. But this rate of packet loss would make VoIP
SF: We don't define how VoIP is carried on the Internet. We don't
say best effort is good, etc. We just say, if VoIP wishes to use
Best Effort, it should use CC.
CP: No one objects to CC for VoIP. In fact, the need for CC is
written into the RTP specs. I just note that VoIP with 50% loss is
unusable. If you get more than a certain loss rate, then it is
better to drop the connection.
SF: The application can decide to drop the flow, if it wishes. It's
not necessary for all applications using this CCID to do this. You
could also make a new CCID that dropped connections above a certain
packet loss rate.
CP: Working at 50% packet loss rate is not a priority for VoIP.
EK: The figure is not 50%, but 20%. Keep in mind, however, that
regular TFRC is 5 to 10 times worse.
SF: The transport protocol should still ensure the maximum rate is
controlled. This is true of all applications.
Magnus Westerlund (MW): I want to understand the formula for header
size - the top line in the slide refers to the "true packet size" -
what is this value?
SF: This is DCCP payload value size.
MW: Ah, that's was not clear to me.
AF: A worked example in the draft would add clarity
SF: Yes, we could add that.
Question: The slide also mentions the number of 1460B, as a maximum
payload size. This size is not fixed, we now have core routers (e.g.,
in Abilene) that use much bigger MTUs!
SF: We could use PMTUD to determine the real size.
SF: It's not clear what we need to do in this case.
AF: The same issue applies to IPv6.
SF: This is described in the spec.
Question: The rules also specify a minimum packet spacing of 10ms - Is
this necessarily a good number? Higher rate codecs also exist (even
unusual VoIP ones at 700 kbps). Is the limit reasonable?
SF: There are a range of apps. Some networks are limited in
bytes/sec some pkts/sec. The number you have (10 ms) is fine, but
this number makes it VoIP only. VoIP-mode is mainly targeted at
MW: A minimum spacing of 10ms is valid for many real media codecs.
SF: The draft will be revised soon.
RATE-ADAPTIVE SPEECH CODECS, Magnus Westerlund
Magnus spoke about codecs from the viewpoint of AVT WG. A total delay
of 200-400ms is typical for whole delivery path. This has
implications on codecs. (see slides)
Codecs may be categorised as: Narrowband - Wideband - Variable
sampling rate. Frame lengths can be either fixed or sample based, but
RTP payloads can also have several speech frames per packet. Speech
may be active (or non-active). RFC3389 describes Comfort Noise (CN),
that may be sent during inactive periods (AMR has a SID frame for
comfort noise). The rate at which comfort noise is sent varies (and
is usally a fraction of the size of normal voice codec frames).
TP: What is the frequency between CN packets? (I have see a lot of
variability reported.) AMR sends one CN of size 5B per 8th frame.
This can vary.
TP: It could be seconds between frames or could be 1/8 (e.g. SID in
Steve Casner (SC): There were even some systems that could send a CN
every frame... although this is an unusual requirement. He
described the EVRC, SMV codec in 3GPP2 CDMA networks (between 8.55
and 0.8 kbps).
TP: The media frame would need two frames per RTP packet. - Sally,
this is an implication for TFRC VoIP mode? Can you reduce the same
bit rate, but keep the same packet rate (?)
TP: So I could keep the same frame, and drop the coding rate, and
stay in TFRC-VoIP mode. Codecs change bit rate, not packet rate.
CP: This is a big thing - you can change packet size, not spacing of
SF: VoIP was designed for applications with a fixed spacing.
AM: Do people really send a separate payload type for CN? - Is this
MW: I can't comment on specific codecs.
SC: This was motivated for codecs that did not have payload formats
for CN (e.g. some high rate codecs). The overhead for changing
between payload formats is not that high.
TP: We do support CN using the CN RTP payload type.
??: Broad voice uses 5ms codecs.
CP: This was a main motivation for this codec, but not sure how
appropriate this is to VoIP(?)
Most codecs can do some type of adaptive change to bit rate. There is
a "user" cost in performing a rate switch (impact depends on codec,
may not be noted - but a user will notice the change in voice
quality). The higher the base quality, the more the users will
notice. Switching to a higher codec rate may not improve user
experience, because they notice a subsequent decrease in quality.
TP: Realvideo allow a switch down, and a switch up. Changes in audio
quality are very percievable (much more so than the changes in the
AF: Is this due to the actual video quality?
TP: The quality of video can be OK, but small.
Stephan ?: Studies in the ITU showed that changes between
narrow-band and wide-band voice codecs can be disturbing. Real
systems do not do this.
CP: Modern video codecs can also have scalability.
You need to know the propagation delay of the path, because this also
impacts the number of codec frames per RTP packet (loss can also be
more significant when several packets are placed in the same RTP
Some important questions are:
- DCCP VoIP mode can introduce extra jitter, how much extra
buffering at the receiver is required?
- Voice activity (DTX) also may have an impact?
Meeting notes taken for DCCP WG by Gorry Fairhurst
(firstname.lastname@example.org). Formatting and minor tweaks by Aaron Falk