[AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribution?

Sally Floyd <floyd@icir.org> Fri, 05 December 2003 09:07 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26955 for <avt-archive@odin.ietf.org>; Fri, 5 Dec 2003 04:07:04 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBvE-000374-Lv for avt-archive@odin.ietf.org; Fri, 05 Dec 2003 04:06:48 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB596m6G011919 for avt-archive@odin.ietf.org; Fri, 5 Dec 2003 04:06:48 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASBuU-0002zb-S5; Fri, 05 Dec 2003 04:06:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS45h-0001jT-Ge for avt@optimus.ietf.org; Thu, 04 Dec 2003 19:45:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28493; Thu, 4 Dec 2003 19:44:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS45f-0005nv-00; Thu, 04 Dec 2003 19:45:03 -0500
Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 1AS45d-0005nm-00; Thu, 04 Dec 2003 19:45:02 -0500
Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.9p1/8.12.3) with ESMTP id hB4N2TQh003089; Thu, 4 Dec 2003 15:02:30 -0800 (PST) (envelope-from floyd@cougar.icir.org)
Message-Id: <200312042302.hB4N2TQh003089@cougar.icir.org>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
cc: 'Eddie Kohler' <kohler@icir.org>, avt@ietf.org, dccp@ietf.org
From: Sally Floyd <floyd@icir.org>
Date: Thu, 04 Dec 2003 15:02:29 -0800
Subject: [AVT] Re: [dccp] RE: Would DCCP kill Internet real-time media distribution?
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt