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

[Eddie Kohler <[e-mail]>]

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

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