Subject: [AVT] [Fwd: [dccp] DCCP, TFRC, and VoIP issue summary]

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Oct 2003 09:40:48 +0100

Hi AVT members,

If you where not a member of either DCCP or MMUSIC you might have missed 
the big discussion after the Vienna IETF. However here is what 
conclusions Eddie makes from the discussion. As many of the topics 
should concern you on this list I forward it. Please review it as it 
will probably have impact on how well things will work in the future.

If you have comments please discuss this on one list AVT or DCCP. Cross 
posting multiple lists are not a good idea at all.

Cheers

Magnus

-------- Original Message --------
Subject: [dccp] DCCP, TFRC, and VoIP issue summary
Date: Fri, 24 Oct 2003 23:13:22 -0700
From: Eddie Kohler <[email-masked]>
To: [email-masked]
CC: [email-masked]

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

_______________________________________________
dccp IETF mailing list: [email-masked]
list info:  https://www1.ietf.org/mailman/listinfo/dccp
wg charter: http://www.ietf.org/html.charters/dccp-charter.html

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt