Subject: Re: [AVT] RE: [dccp] Re: DCCP Media Guide

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 01 Dec 2003 09:34:56 -0500

All,

I think Steve has hit the essence of the issue.

Some comments in-line.

Michael Ramalho

At 11:10 AM 11/27/2003 -0800, Stephen Casner wrote:
>Marshall,
>
> > most TCP implementations are badly tuned for broadband
> > and don't actually deliver much more than 500 kbps at best.
>
>Banking on that for a media protocol design would be unwise.
>
> > I notice empirically that UDP flat rate audio and video can co-exist
> > with tcp in practice, and wonder if poor tcp performance might be
> > one of the reasons why.
>
>Sure.  Flat-rate is the key.  If the UDP traffic does not back off in
>response to TCP's probing, then TCP stays within the bandwidth that is
>left.  The root of this whole discussion is that if you have ever more
>flat-rate UDP traffic, it will push all the TCP out of the way until
>the network is saturated with UDP traffic, then the UDP streams will
>experience loss.

I did some research on this issue for a major RBOC about 5 years
ago when VoIP was the "imminent threat" to the PSTN. The study
was for "best effort" networks (the story changes with QoS provisioned
flows for UDP/VoIP).

The whole issue on whether UDP-based applications would
"crowd out" TCP to oblivion was the MIX of traffic ON A
PARTICULAR service providers IP network.

If VoIP/UDP was a minority traffic of the mix ... TCP backed off a
little ... was never starved to oblivion (because UDP was a minority
traffic type) ... network collapse did not occur ... and life went
on (even though the UDP was "unfair" to TCP in the bandwidth
sharing socialistic sense).

If, however, the dominant traffic was VoIP/UDP (perhaps an
IP network set up as an Internet Telephone Service Provider) the
story was different. First, said service provider needed to size
(that is traffic engineer) their network for: 1) all the VoIP/UDP
traffic expected to be "admitted" and 2) have enough bandwidth
"left over" for the anticipated TCP traffic running on the network
(e.g., VoIP signalling, messaging, etc.). There is no getting
around "traffic engineering" for this case! It becomes very much
like QoS provisioning your whole network, except that you
size the network based on monitoring UDP and TCP trends rather
than admitting on every UDP flow. You also "allocate" some
percentage of your network for TCP traffic (to ensure it's
timely delivery/performance). This is doable for large backbone
networks due to the law of large numbers.

Now forgetting "fairness" for a while and considering only: 1)
network collapse and 2) "best effort networks" ... the question
comes down to insuring that UDP applications do not EVER
become close to being the dominant traffic source. One way
is forecasting - monitor your network to make sure UDP isn't
becoming your dominant traffic source. If UDP applications are
becoming a dominant source you must do something about
it! You must either:
1) specifically admit/police UDP traffic (essentially providing
a QoS mechanism for the flow or aggregate flow) or
2) design something in DCCP (or equivalent transport) to
back it off or shut it down if the required rate changes are
"too large".

[This is a vast simplification. The needed traffic engineering would
also consider the performance of the remaining TCP
applications in the provisioning/sizing of the network design.]

If DCCP only did #2 above .... it would still be "unfair to TCP"
but it's unfairness would not lead to network collapse. Unfortunately
the DCCP flow cannot figure out that the cause of the congestion
is that the dominant traffic type in a given network traversed is
non-elastic (or near in-elastic). This is a hard problem - you need
network help here (use congestion notifications to provide hints
to the transport?).

I see DCCP as trying to go a step further and, out of "bandwidth
fairness" to TCP, it is trying rate control the inherently "near in-elastic"
application. This leads to the present quandary of DCCPs unsuitability
for VoIP/UDP flows in best effort networks.

Sorry for the long post - but this is a hard problem.

>The TCP folks say that UDP traffic is unfair; DCCP
>is being developed as a response.  Now in this conversation, we're
>discussing how to keep TCP from pushing DCCP out of the way.

This is hard because any particular flow doesn't know the overall
network condition.

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

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

---

From: [email-masked] (lazzaro)
Date: Mon, 1 Dec 2003 10:14:50 -0800 (PST)

> "Michael A. Ramalho" <[email-masked]>
>
> If UDP applications are becoming a dominant source you must do
> something about it! You must either:
>
> a QoS mechanism for the flow or aggregate flow)

This is an opportunity, folks -- for QoS deployment, for multicast
deployment, and for the migration of real-time non-standardized UDP
apps like networked games to RTP and SIP (to take advantage of QoS and
multicast-enabled networks).

---------------------------------------------------
John Lazzaro    http://www.cs.berkeley.edu/~lazzaro
     lazzaro [at] cs [dot] berkeley [dot] edu     
---------------------------------------------------

---

From: John Lazzaro <[email-masked]>
Date: Mon, 1 Dec 2003 10:16:14 -0800 (PST)