Subject: RE: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribut ion?

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Dec 2003 15:15:10 -0500

> I think the key question for the DCCP folk is, What does it mean for
> congestion to be "bad enough that signalling shuts down the flow"?
> 
> 1. The loss rate is greater than some fixed constant.  
> (Independent of flow
>    rate or RTT.)
> 2. Loss rate plus RTT indicate that the TCP-friendly rate has 
> dropped below
>    the app's transmit rate.
> 3. Loss rate plus RTT indicate that the TCP-friendly rate has 
> dropped below
>    some fraction -- say half -- of the app's preferred transmit rate.
It's closest to (1).  There really isn't a "fixed" constant, because
what's acceptable quality is in the eye of the beholder, but probably,
the signalling system would establish a fixed loss rate, below which
it would take action.  It would not matter what else was happening;
that is, whatever the reason for the loss, the quality of the media
is below the point where it should be maintained. 

It will then lower the rate, or drop the flow.

For voice, the loss rate is something in the single digit percent
range for high quality, and I don't know, maybe 10%-15% or so for 
low quality services.  I don't think anything approaching 30% is
useful, even if it's free.  You get to do some averaging.

> 
> If your app wants (1), then we are not the right protocol for you.
> Arguably you are bad Homer and should get no donut on the public
> best-effort Internet.
Agree that DCCP is probably not useful for interactive media.
For non-interactive media, there is some hope, because slow-start
is probably not much of a problem.  However, I still don't see
how you get to maintain a fixed rate as TCP flows come and go,
even with a lot of buffering.  Won't TFRC in the face of
congestion lower your rate?  That would not work; the rate must
be pretty constant (averaged over the buffer length).

Disagree that media is a bad Homer.  TCP is broken.
Nowhere is it written that TCP=best effort.

> 
> On the other hand, if (2) or (3) is the case, then we *want* 
> to be your
> protocol.  We provide a signalling path for the receiver to verifiably
> inform the sender of the loss/mark rate.  We provide 
> different mechanisms
> for calculating the TCP-friendly rate.  The app can decide 
> how to react to
> the rate; such as by reducing once, then cutting off.  (DCCP does not
> require apps with smoothly varying rates!  It provides a 
> smoothly varying
> _reference_ rate; the app's rate need not smoothly vary, as long as it
> stays within some factor of the reference rate.)
I think this is all foolish.  You have to assume that the TCP flows
are coming and going, and the media flow is pretty fixed.  I don't 
see how DCCP will maintain the original TCP-friendly rate, even if
that rate was forced to be acceptable.  You can say that it
varies the TCP-friendly rate slowly, but not zero, right?
Time scales here are minutes to hours.  You need constant rate
over minutes to hours.

> 
> As we've discussed, the more interactive, CBR-flavored apps 
> would find it
> difficult to use DCCP now.  The issue seems to be slow start. 
>  ("Filler
> data", for example, is really about slow start: filler data is one
> mechanism for avoiding slow start after an idle period.)
Well, it's one of a couple of problems.
All the current apps are CBR flavored, Philippe's suggestions
notwithstanding.  Slow start is a killer for interactive, for sure.

> 
> So, thought experiment for interactive, CBR-flavored apps:
> 1. Is slow start in fact the only problem?
No, I think there is no way to maintain a constant rate
over the time period.

> 2. What would these apps give up in return for avoiding slow 
> start?  (Maybe
>    the apps would limit their transmit rate to below some 
> absolute number,
>    or shut off quickly if a "fast start" caused loss.  In 
> return, maybe the
>    app would avoid *any* slow start, or maybe it'd avoid slow 
> start after
>    idle periods.)
It could do any form of signalling of its intentions

It can limit its rate to a fixed number; it can even negotiate
that number, and, if necessary, once, it can lower the number.

It can react to loss by lowering the rate (once) or shutting down

> 3. Would any such compromise be acceptable for the DCCP folk? 
>  (Need to
>    think more.)
> 
> > "appropriately" means not being greedy; the biggest actual 
> problem that 
> > exists today is that TCP destroys voice, not that voice 
> destroys TCP.
> 
> I assume you see this happen.  We've been throwing around 
> assumptions about
> when -- do you agree?  Does it happen mostly if the congested 
> link has low
> statmux?  Any references?
I have no reference data.  My sense is that it happens under
both low and high statmux, but I'm not really sure its the same
mechanism in both cases.  Need more data I suspect.

Brian 

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

---

From: Eddie Kohler <[email-masked]>
Date: Fri, 05 Dec 2003 13:22:35 -0800

> However, I still don't see
> congestion lower your rate?

Not necessarily. The TCP equation takes in an RTT and a loss event rate,
and produces a reference rate. This reference rate can be thought of as
"what TCP would achieve sending full blast."

If you were originally sending less than what TCP would have sent (possibly
the normal case?), then slightly increased loss rates would not reduce the
reference rate below your actual transmit rate.  Continue sending at your
preferred rate.

Caveat: The reference rate *is* limited to (2 * your recent transmit
rate).  But the factor of 2 is pretty wide wiggle room.

Eddie