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

From: Sally Floyd <[email-masked]>
Date: Thu, 1 Mar 2007 17:31:54 -0800

Lars -

I just read it, and I think it is quite nice.

My only feedback is that in Section 3.1, when the document says that 
applications
should consider implementing TFRC "or otherwise ensure that the 
application
complies with the congestion control principles", it might be worth 
mentioning
TCP-like congestion control as well.  E.g., "TFRC, TCP-like congestion 
control,
or otherwise ensure...".

(It is on my TODO list to add a modified CCID2 to DCCP that does 
TCP-style
congestion control with AIMD parameters for slowly-responding congestion
control.  A start is at
"http://www.icir.org/floyd/papers/draft-floyd-dccp-ccid2slow-00b.txt", 
but
unfortunately, I am slow at getting to things these days.)

- Sally
http://www.icir.org/floyd/

A few nits noticed in passing:

Section 3.1:
"instead of ignoring it" -> instead of ignored"

Section 3.2:
"choose to not" -> "choose not to"

Section 3.3:
"UDP does also not" -> "UDP also does not"
"at the received" -> "at the receiver".

---

From: Lars Eggert <[email-masked]>
Date: Wed, 7 Mar 2007 14:31:16 +0200

Hi,

thanks for the feedback!

On 2007-3-2, at 3:31, ext Sally Floyd wrote:
> My only feedback is that in Section 3.1, when the document says  
> that applications
> TCP-like congestion control as well.  E.g., "TFRC, TCP-like  
> congestion control,
> or otherwise ensure...".

I assume you mean DCCP CCID2 by "TCP-like congestion control?"

If so, the first paragraph in Section 3 alreadys recommends that apps  
use a congestion-controlled protocol instead of UDP, and points to DCCP.

Or am I misunderstanding?

Lars

---

From: Sally Floyd <[email-masked]>
Date: Wed, 7 Mar 2007 09:47:59 -0800

Lars -

> Or am I misunderstanding?

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?

- Sally

---

From: Lars Eggert <[email-masked]>
Date: Fri, 9 Mar 2007 09:29:02 +0200

On 2007-3-7, at 19:47, ext Sally Floyd wrote:
>> If so, the first paragraph in Section 3 alreadys recommends that  
>> apps use a congestion-controlled protocol instead of UDP, and  
>> points to DCCP.
>>
> 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
> 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
> 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?)

Thanks,
Lars

---

From: Sally Floyd <[email-masked]>
Date: Fri, 9 Mar 2007 11:01:15 -0800

>> action, you also mention TCP-like congestion control, by name.  Just 
>> to make it clear that it
> 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.

- Sally

---

From: Lars Eggert <[email-masked]>
Date: Tue, 13 Mar 2007 11:44:02 +0200

> if that seems better to you.

Works for me - thanks.

Lars

---

From: Colin Perkins <[email-masked]>
Date: Mon, 19 Mar 2007 09:36:51 +0100

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
>>> [CCID2]" instead of just "CCID2", I think.  Because CCID2  
>>> contains some DCCP-specific stuff that wouldn't
>> 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.
>>
>> 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:

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/

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Mar 2007 14:12:48 +0300

> RFC 3551 has the following guidelines for multimedia applications:
...
> lines to explain what it means to "otherwise ensure" might be useful?

Thanks for the pointer. I've revised my local copy to incorporate  
this; a diff relative to -01 is attached.

Lars