Subject: [MMUSIC] DCCP, TFRC, and VoIP issue summary

From: Eddie Kohler <[email-masked]>
Date: Fri, 24 Oct 2003 23:13:22 -0700

Hi all,

Several months ago, we had a pretty lively discussion on these lists about
why TFRC and/or DCCP might be inappropriate for VoIP and other apps. I
wanted to summarize again the problems that people have brought up, and
where we stand on solutions. Comments welcome.

A. Complexity

   The existing DCCP specification is simply too complex for resource-
   constrained implementations, which might be common for voice.

   * This complexity seems important and not onerous for host stacks. We
   hope that CCID 3-Thin shows it's possible to simplify DCCP's
   requirements for resource-constrained implementations without radical
   surgery on the base protocol.

B. Slow-start

   TCP-friendly congestion control algorithms must slow-start up to their
   sustained rate. Voice apps might like to start with their full bandwidth
   right away. Plus, the initial TFRC rate seems very slow (1 packet per
   RTT).

   * We have updated the CCID 3 draft to allow initial TFRC rates of up to
   4 packets per RTT (or 4380 payload bytes per RTT), in line with recent
   TCP practice (RFC 3390). For a This supports a 40ms _initial_
   packetization interval for any RTT up to 160ms: not bad at all.  And we
   might consider allowing a larger initial window when packet payloads are
   small; this would require a bit of research on whether many small
   packets is actually equivalent to few large packets in terms of
   congestion.

C. Rate slows down during idle periods

   The TFRC allowed sending rate will drop down to something very small
   (2-4 packets/RTT) when the sender is idle. This may cause problems
   particualrly with VoIP conversations, which are naturally idle-one-way
   then idle-the-other-way. The rampup from the small rate to the fair rate
   may take several to many RTTs, ouch.

   * The solution for slow start applies here. Beyond that, we recommend
   sending probe packets if any slowdown during an idle period is
   unacceptable; you don't get to reserve bandwidth in the best-effort
   internet. These probe packets could easily consist of required
   acknowledgements.

D. Rate will not increase during app-limited period

   If the application is sending at rate R, the allowed rate will not
   increase much beyond R (say, more than 2R) until the app "probes" by
   transmitting at a faster rate. The reason: DCCP determines the allowable
   maximum rate by monitoring packet drops. Thus, DCCP "can not tell the
   application when to increase its rate unless the application 'probes'
   the network first by ... increasing its rate."  (Phillipe Gentric)

   * A related issue, and again, we can't do much better in the current
   internet than having the application send probe packets: you don't get
   to reserve bandwidth you aren't using. Nevertheless, there shouldn't be
   much problem with the sender abruptly doubling its sending rate in this
   situation, assuming TFRC's observed loss event rate is low enough to
   allow it.

E. Congestion control means variable rate

   Must an application with discrete sending rates send at a rate strictly
   bounded by TFRC's allowed rate? Could we allow some flexibility, so that
   it could send at, say, any rate <= 1.8*TFRC_allowed_rate?

   * There probably wouldn't be any problem with this, but it should be
   explored in a separate document. Does anyone want to write up a draft
   about CCID 3 adapted for a sender with discrete sending rates?

F. Rate changes/oscillations

   There are application costs, possibly significant ones, associated with
   changing rates. Current codecs switch rates poorly; actual devices tend
   to swap in a new codec. Also, for audio at least, people find the
   glitches caused by frequent rate changes distracting. Thus, if the
   application has to change its rate frequently, because of CC, that's a
   problem.

   * A solution to issue D would apply here. Furthermore, we should not
   solve this problem generically; different applications will want
   different behavior. For example, Tom Phelan described a procedure where
   bandwidth is probed at the beginning of the connection, then a codec
   starts at a lower rate than the probe rate; if congestion causes the
   rate to drop below this, the connection terminates.

G. Multiple streams

   An application that had both audio and video to send might use 2 DCCP
   connections. Could the application choose how its bandwidth is allocated
   among those connections?  (Phillipe Gentric)

   * We haven't made progress on this. It's at least somewhat problematic
   since the end nodes can't necessarily assume that the two connections
   take the same path, with the same quality of service on all parts of the
   path.

Here are some non-issues: things people have brought up that I think the
DCCP spec already handles well.

H. Low delay

   It's very important to minimize packetization overhead and effects of
   the send buffer.

   * An API issue, and DCCP was designed with this in mind.

I. Control over the send buffer

   What happens when packets need to be dropped (because TFRC demands a
   lower rate than the application wants)? Some would like packets to be
   dropped by the TFRC stack, either by dropping the first packet, or the
   last packet, or the lowest-priority packet; others would like the
   application to be in direct control.

   * This is an API issue, and DCCP seems flexible enough to handle any of
   those APIs, or others.

J. Pushing against the maximum rate (streaming media)

   TFRC always pushes against its maximum rate until a loss, which will
   force a decrease in the allowable rate. This induces periodic
   distortion. Can we minimize this by providing TFRC with a maximum rate,
   beyond which it will not push? (Damon Lanphear)

   * Absolutely---TFRC will not send more data than the application
   provides.

Eddie

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic