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

From: Eddie Kohler <[email-masked]>
Date: Tue, 02 Dec 2003 16:35:32 -0800

(To protect itself from "greedy TCP flows" gobbling up available
bandwidth?)

No.

TFRC exists to smooth out responses to congestion.  A single loss (such as
that caused by TCP probing) does not halve the TFRC transmit rate.  In many
cases it will cause only small changes (which, as we've discussed, the
application might be able to ignore).  In many cases it will not change the
rate at all.

If the congested link has high levels of statistical multiplexing, the TCP
flows won't likely gobble up the available bandwidth anyway -- even during
a silent period.

If the congested link has low levels of statmux -- like one DCCP flow and
one TCP flow -- then yes, the TCP would try for the available bandwidth.
And during a silent period, the TFRC flow would have to transmit something
so it wasn't crowded out entirely.  But this amount would be *half* the
nominal rate, or perhaps less.  Not twice.

Eddie

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

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 02 Dec 2003 21:03:25 -0600

> ....

This may be an encouragement to the codec folks in the future to stop doing
silence detection since it would be better to always have something to send.
But, if people suddenly realize that turning off their encoder silence
detection immediately gives them better voice quality and start to do so in a
large scale, what good it would do to the network? Would IAB have the power to
tell people not to do so?

regards,
-Qiaobing

> 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

---

From: Eddie Kohler <[email-masked]>
Date: Tue, 02 Dec 2003 19:11:10 -0800

> tell people not to do so?

TCP-friendliness without silence suppression is probably better for the
best-effort Internet than non-TCP-friendliness with silence suppression.

Eddie

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 03 Dec 2003 11:38:58 -0600

> best-effort Internet than non-TCP-friendliness with silence suppression.

Eddie,

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

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?

regards,
-Qiaobing

---

From: Eddie Kohler <[email-masked]>
Date: Thu, 04 Dec 2003 19:15:32 -0800

> 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

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 05 Dec 2003 01:48:56 -0500

On Thu, 04 Dec 2003 19:15:32 -0800
> > 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