Re: [AVT] Re: [dccp] Would a DCCP flow need to send 2x its preferred rate?

["Marshall Eubanks" <[e-mail]>]

On Thu, 04 Dec 2003 19:15:32 -0800
 Eddie Kohler <[e-mail]> wrote:
> > I wish I could be as optimistic as you. I wonder if anyone on the list
> > has some numbers that can show what percentage of additional media data
> > will be injected into the network if codecs would stop doing silence
> > detection (motion detection for video).
> 

Hello;

(Just got back from the airport, and am working backwards in e-mails)

From Stanislaw's indispensible netflows :

http://netflow.internet2.edu/weekly/20031124/

Reports on traffic on all Abilene routers

Table 7 (for the most recent week).

Http        : 10.6 % of all octets for the week
https       :  0.52 %
IPSEC + SSH :  2.68 %
Multicast   :  1.79% (for fan-in, not fan-out)
"Subset of VOIP" : 0.01 %

File Sharing : Between 15.21 and 52.08% (depending on how much of the "unknown" traffic is f.s.)

Oh, just for reference :

Table 8 

TCP 92.22 %
UDP  5.16 %

So, my answer to your question is of order 0.01% (as I do not believe that at present the majority
of VOIP is encrypted).

Regards
Marshall Eubanks

> For the app Henning mentioned (multi-party, non-multicast conferencing),
> silence suppression is a huge win.  (With 100 participants and silence
> suppression, you have 1-2 inbound streams' worth of data and 100 outbound
> streams' worth; without it, you have 50-100 inbound streams and 100
> outbound streams.)
> 
> On the other hand, say you have:
> - 100 Kb/s uplink
> - 100 person-to-person multimedia connections on the link
>   - Each of which uses 2 Kb/s when not silent
>   - and is silent 50% of the time
> - and 100 TCP flows on the link (which are coming and going).
> 
> A back of the envelope analysis: (Comments welcome)
> 
> 1. If the media flows use silence suppression but not congestion control,
>    they will fit in the link on average, but crowd out the TCP flows.
>    Useful work getting done: 100.  (1 "Work" unit == 1 TCP flow achieving
>    >= 500 b/s, OR one media flow achieving its preferred nonsilent rate
>    [2 Kb/s].)
> 
> 2. If the media flows use congestion control but not silence suppression,
>    media and TCP will share the link, but each media flow is limited to
>    approximately 1/4 its preferred nonsilent bandwidth.  Useful work
>    getting done: 125.
> 
> 3. If the media flows use congestion control and send 1/2 rate filler data
>    during silent periods, media and TCP will share the link, but each media
>    flow is limited to approximately 1/3 its preferred nonsilent bandwidth.
>    Useful work getting done: 133.
> 
> *None* of these results are particularly attractive.  What you really want
> is 150 units of work or something like it.  But the first result is worst.
> 
> The easiest way to get 150 work units is through bandwidth reservations,
> and thus QoS.  QoS is also the only reasonable way to privilege the media
> traffic above TCP.
> 
> Note that "all-or-nothing" media apps, which would either send at their
> preferred rate or not at all, get a tough break; given the TCP flows, the
> fair rate is < 1 Kb/s, too low for any media apps to send.  (And thus
> leading to 100 work units.)  I'm not sure what the right solution is.
> There might not be a solution apart from QoS/bandwidth reservations.
> 
> > Fundamentally, I am concerned that this DCCP
> > "app-who-sends-more-will-get-rewarded" feature will be taken advantage of
> > in the wrong way (the draft that starts this discussion is the first
> > attempt for this, but it won't be the last).
> > 
> > If this behavior of "sending filler data when no real data to send"
> > becomes a recommended practice for media-over-DCCP (as you and Tom seem
> > to suggest), what would stop the same recommendation be made for app over
> > TCP? For an app over a long lived TCP connection, the sender can also
> > benefit from sending "filler data" to keep the pipe from collapsing, so
> > as to avoid the penalty of going through another slow start when it has
> > real data to send next time. But I think this is hardly something that
> > should be recommended for TCP based apps. Why should it be more
> > acceptable for DCCP then?
> 
> It is a tough tradeoff.  
> 
> * Sending filler data is clearly bad.
> 
> * On the other hand, the Internet works not because we judge whether the
>   *contents* of a data stream are worthwhile, but because we ensure that
>   data streams are friendly to one another.  They do not continue
>   transmitting at high rates in the face of congestion.  They do not cause
>   congestion collapse.
> 
>   Sending filler data *limited by congestion control* won't cause
>   congestion collapse.  The app will not send *more* filler data after a
>   loss event; it will send less.
> 
> My feeling has therefore been that filler data *limited by congestion
> control* is better for the Internet than non-congestion-controlled media
> traffic.  But it is tough.
> 
> Eddie
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt


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