Re: [Tsvwg] comments wanted: draft-eggert-tsvwg-udp-guidelines

[Colin Perkins <[e-mail]>]

On 9 Mar 2007, at 20:01, Sally Floyd wrote:
>>> I was just suggesting that in the sentence where you mention  
>>> TFRC  "or otherwise..." as recommended
>>> action, you also mention TCP-like congestion control, by name.   
>>> Just to make it clear that it
>>> TFRC isn't necessarily being recommended over TCP-like congestion  
>>> control, for the purposes of
>>> this document.  (If the application is implementing it, it is  
>>> better called "TCP-like congestion control
>>> [CCID2]" instead of just "CCID2", I think.  Because CCID2  
>>> contains some DCCP-specific stuff that wouldn't
>>> be included if an application was implementing it itself.)
>>>
>>> So:  "TFRC, TCP-like congestion control (as in [CCID2]), or  
>>> otherwise ensure..."
>>>
>>> Does that make sense?
>>
>> I'm not sure it goes with the flow of the argument. The document  
>> says in in the first paragraph of Section 3 that apps should  
>> really be using an existing congestion controlled transport  
>> instead of UDP, and includes DCCP as an example of what to use (I  
>> could point to specific CCIDs here).
>>
>> The rest of Section 3 applies to apps that for some reason chose  
>> not to use one of the congestion-controlled protocols, including  
>> DCCP, and instead chose to use UDP. These apps could still  
>> implement TFRC for UDP.
>>
>> Is your suggestion to point out that they could also implement a  
>> TCP-like windowing mechanism instead of TFRC? (In which case  
>> calling it CCID2 is confusing, because that is tied to the use of  
>> DCCP, no?)
>
> Yep.
> So it could just say:
> "TFRC, TCP-like congestion control, or otherwise ensure..."
> if that seems better to you.

RFC 3551 has the following guidelines for multimedia applications:

       If best-effort service is being used, RTP receivers SHOULD  
monitor
       packet loss to ensure that the packet loss rate is within
       acceptable parameters.  Packet loss is considered acceptable if a
       TCP flow across the same network path and experiencing the same
       network conditions would achieve an average throughput, measured
       on a reasonable timescale, that is not less than the RTP flow is
       achieving.  This condition can be satisfied by implementing
       congestion control mechanisms to adapt the transmission rate (or
       the number of layers subscribed for a layered multicast session),
       or by arranging for a receiver to leave the session if the loss
       rate is unacceptably high.

       The comparison to TCP cannot be specified exactly, but is  
intended
       as an "order-of-magnitude" comparison in timescale and  
throughput.
       The timescale on which TCP throughput is measured is the round-
       trip time of the connection.  In essence, this requirement states
       that it is not acceptable to deploy an application (using RTP or
       any other transport protocol) on the best-effort Internet which
       consumes bandwidth arbitrarily and does not compete fairly with
       TCP within an order of magnitude.

It may be more detail than you want, but including text along these  
lines to explain what it means to "otherwise ensure" might be useful?

-- 
Colin Perkins
http://csperkins.org/