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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Dec 2003 09:42:35 -0500

Sally

I think the primary control for media streams is going to be 
admission control.  There is a missing link to make this work,
which is that there is no feedback path from the media flow to the
signalling (RTP to SIP/RTSP), but fundamentally, if a media flow
experiences congestion, it will be downshifted to a lower rate 
(once, maybe) or shut down.  It's pretty reasonable to expect that
such congestion control could be widely deployed.  I think that
is the way congestion collapse should be addressed.

It's harder to deal with the relative fairness of TCP vs media flows.
None of the mechanisms that I have heard proposed will work in my
opinion.  Work means that you get acceptable voice/video quality up 
to the point where congestion is bad enough that signalling shuts 
down the flow.  Media flows can't deal with "fair" in the sense that 
TCP does.  There is no "fair", there is only "all or nothing". 

One possible avenue of exploration is to look more into aggregate
behavior; you CAN probably assert a more TCP friendly "rate control"
if you deal with the aggregate of media traffic, even if the individual
components of the traffic experience all or nothing flow control.

Ultimately, however, the actual media flow can't do anything interesting
with existing TCP mechanisms.  It only has a very gross rate control,
it can't probe, it's silly to send filler, and it can't use any form 
of a window.  Similarly, TCP doesn't have any way to know if the media 
flow is present, and thus adjust it's behavior appropriately.  
"appropriately" means not being greedy; the biggest actual problem that 
exists today is that TCP destroys voice, not that voice destroys TCP.
I think, naively perhaps, that it is possible to design mechanisms 
that would work together, but it is highly unlikely to be possible to
do this from one side; TCP must change as well as UDP (or a replacement).

I suspect that if a service provider is providing both a data service
and a voice service over that data service, that it will drop all the
TCP traffic before it drops any voice traffic, because, so far, the
pricing for a voice bit is several orders of magnitude larger than
a data bit.  If the data service provider is not also the voice service
provider, it's not clear to me why he would care which customer bits
get treated differently.  Conventional wisdom in carriers is that
flat rate Internet service makes small profits, while voice/video 
makes a lot more.  Don't know if that's really true, or will remain true,
but I'll bet you will scream much more loudly if your voice/video
sounds/looks bad than if your browser slows down.

Of course, deployment of QoS mechanisms would be helpful. 

Brian

> -----Original Message-----
> From: Sally Floyd [mailto:[email-masked]]
> Sent: Thursday, December 04, 2003 6:02 PM
> To: Rosen, Brian
> Cc: 'Eddie Kohler'; [email-masked]; [email-masked]
> Subject: Re: [dccp] RE: Would DCCP kill Internet real-time media
> distribution? 
> 
> 
> Brian -
> 
> >Slow start is not
> >a practical thing for interactive use, sorry.
> 
> I have not read all of the earlier email, so I might be repeating
> things that have already been said.
> 
> Currently, slow-start for TCP allows an initial window of up to
> four packets.  The reason that the Internet still works plausibly
> well even with interactive traffic that does not obey slow-start
> is that the vast majority of the packets in the Internet still use
> TCP, and still abide by slow-start and the other mechanisms of TCP
> congestion control.  If the majority of the traffic on a congested
> link was interactive traffic that did not use slow-start, and that
> also did not use any admissions control or explicit feedback from
> routers allowing high initial windows, I don't think that any of
> the interactive users would be very happy with the results.  This
> would particularly be true, I would conjecture, in a network with
> only interactive traffic, with no TCP traffic to back off and make
> space for the interactive traffic.
> 
> For a best-effort network that includes TCP traffic, there is the
> additional concern of the fairness for the TCP users.  There is no
> reason why best-effort interactive UDP traffic has a higher right
> to bandwidth or to low delay that does the best-effort TCP traffic
> (whose users are paying the same monthly fees to their service
> providers).  Remember that the TCP traffic could easily be someone
> doing a web transaction that is perfectly important to them or to
> their business, and for which they are expecting the same prompt
> response times from the network that the interactive users are
> expecting.
> 
> My own prediction is that, if there seems to be a danger of congestion
> in best-effort links due to best-effort UDP traffic that is not
> TCP-friendly, the routers at the congested links would end up
> preferentially dropping the UDP traffic in times of high congestion
> (since this is easier than more precisely-targetted forms of
> preferential dropping at the router).  But maybe things will work
> out better than that, and routers will have mechanisms to precisely
> identify those flows that aren't using decent end-to-end congestion
> control in a time of high congestion, and preferentially drop packets
> from only those flows.  No telling...
> 
> - Sally
> http://www.icir.org/floyd/
> 
> 
> 

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

---

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

> TCP does.  There is no "fair", there is only "all or nothing". 

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.

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.

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.)

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.)

So, thought experiment for interactive, CBR-flavored apps:
1. Is slow start in fact the only problem?
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.)
3. Would any such compromise be acceptable for the DCCP folk?  (Need to
   think more.)

> 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?

Eddie

---

From: Guy T Almes <[email-masked]>
Date: Sat, 06 Dec 2003 13:23:15 -0500

Steven,
  What does seem clear is that, *if* using delay+loss signals together you 
can maintain modest-sized and stable-sized queues at the bottleneck link, 
then there are many positive implications for the net, both for the 
routers/switches and their engineering and for the applications, 
particularly jitter-sensitive ones, that share the bottleneck link.

  It would seem that the challenge is to accomplish the task of maintaining 
such queues in a highly dynamic environment with many and many kinds of 
flows.
  With an increasing reach of the international advanced production 
networks (e.g., Internet2/Abilene in the US, Geant in Europe) being made up 
of 10 Gb/s links, this challenge is ever more crucial.

  I look forward to hearing from others on the thread.

  Regards,
        -- Guy

--On Friday, December 05, 2003 09:51:56 -0800 Steven Low <[email-masked]> 
wrote:

>
> Thanks everyone for the intresting discussions from various
> perspectives.   What are your expert opinions on the coexistence
> of a delay-based TCP with (let's assume, essentially) fixed rates
> of media flows?   Granted that there are many challenges in filtering
> out noise in delay measurements, etc, but these seem more
> surmountable than the fundamental difficulty of a loss-based
> scheme where TCP must periodically push the queue to overflow,
> thus squeezing out other flows that are not as (or more)
> aggressive than TCP.    In a delay-based scheme where (e.g.) a
> TCP flow will stabilize when it maintains a certain amount of queue
> (instead of pushing it over the cliff), it will then coexist peacefully
> with media flows, each sharing the link at a rate that's proportional
> to their buffer shares, without the protocol itself producing severe
> oscillations.
>
> Again, there are of course challenges to filter delay noise, ensure
> fairness, etc, but it seems to avoid a more difficult problem of a
> loss-based scheme.
>
> Steven
>
>
>
> Rosen, Brian wrote:
>
>> Sally
>>
>> 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
>>
>>
>>
>
> --
> _____________________________________________
> Steven Low                assoc prof, cs & ee
> http://netlab.caltech.edu tel: (626) 395-6767
> [email-masked]          fax: (626) 568-3603
>
>
>
>

---

From: Steven Low <[email-masked]>
Date: Fri, 05 Dec 2003 09:51:56 -0800

Steven