Datagram Congestion Control Protocol WG (dccp)
Monday, March  7 at 1300-1500
CHAIR: Aaron Falk (falk@isi.edu)

AGENDA
  - 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
      draft-ietf-dccp-user-guide-03.txt
  - TFRC for Voice over IP, Sally Floyd
      draft-ietf-dccp-tfrc-voip-01.txt
  - Presentation on Rate-Adaptive Voice Codecs, 
      Magnus Westerlund

-----

AGENDA BASHING

  No changes
  Note: the meeting is being unicast streamed

-----

WG STATUS

  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
  the session).

  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
  cross fertilisation...

  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
    happy. 

  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.
    PMTU
    DoS
    etc.

CCID2 and CCID3 also have minor changes.

Eddie promised to post the changes to the list.

----

DCCP USER GUIDE UPDATE, Tom Phelan

  draft-ietf-dccp-user-guide-03.txt

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
  TFRC_VoIP...

  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
  Director). 

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
  the meeting)

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
behaviours.

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
  packets? 

  EK: What's the order which is worst (TCP, TFRC, TFRC-VoIP)?

  SF: ??

  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
  congestion.

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
  unusable.

  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
  VoIP.

  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
  AMR). 

  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 (?)

    SF: Yes.

  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
  packets.

  SF: VoIP was designed for applications with a fixed spacing.

  AM: Do people really send a separate payload type for CN? - Is this
  real?

  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
  video).

  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
packet).

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
(gorry@erg.abdn.ac.uk).  Formatting and minor tweaks by Aaron Falk
(falk@isi.edu).