Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <017a01cf5faf$b8e16b10$2aa44130$@stahl@intertex.se>
Date: Thu, 24 Apr 2014 14:27:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F0E8FA2E-2C3A-43A3-A12F-17A50D7B2C2A@ifi.uio.no>
References: <5357B281.1030900@alvestrand.no>
 <1447FA0C20ED5147A1AA0EF02890A64B1CFD9001@ESESSMB209.ericsson.se>
 <017a01cf5faf$b8e16b10$2aa44130$@stahl@intertex.se>
To: Karl Stahl <karl.stahl@intertex.se>
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/efAGyQTHKoQj7lNd1E4QyXCLGJc
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Pictures of congestion control on the Internet - which
 is more realistic?
Precedence: list

On 24. apr. 2014, at 13:24, Karl Stahl wrote:

>=20
>=20
> -----Ursprungligt meddelande-----
> Fr=E5n: rtcweb [mailto:rtcweb-bounces@ietf.org] F=F6r Stefan H=E5kansson=
 LK
> Skickat: den 24 april 2014 11:57
> Till: Harald Alvestrand; rtcweb@ietf.org
> =C4mne: Re: [rtcweb] Pictures of congestion control on the Internet - =
which is
> more realistic?
>=20
> On 2014-04-23 14:31, Harald Alvestrand wrote:
>> I quote Karl's piece below, because I want other's opinion of whether=20=

>> it's a realistic picture.
>>=20
>> My impression is that it is not - in particular that:
>>=20
>> - Lots of interactive traffic goes over the Internet today without=20
>> layer 2 separation - All UDP endpoints that use the open Internet =
have=20
>> some form of backoff on congestion - using delay, packet drop or =
(most=20
>> likely) both to detect congestion
>>=20
>> I'm writing the transport document based on those assumptions - that=20=

>> we should specify something that will work as well as it can over an=20=

>> Internet that does not care, and try to allow for better things to=20
>> come along later.
>>=20
>> Am I wrong to write it like this?
>=20
> My impression (I have no facts, so I can be completely wrong; it would =
be
> nice if someone could show figures) is that most UDP traffic on the =
internet
> comes from modern (SW implementations) audiovisual communication, from
> torrent traffic and from other special transport built on top of UDP =
(quic
> is one example, but there are other used by e.g. games). I think all =
of them
> back off, so I think you are right.
>=20
> There is some older stuff that do not back off, but does it really =
generate
> enough traffic to be relevant?
>=20
> [Karl] If file transfer type of traffic (that wants max bandwidth =
during
> shortest time) run over UDP (like e.g. torrent) their endpoints need =
to
> back-off when seeing congestion - just like TCP has built-in. That is =
also
> one of the mechanisms build into SCTP (to "operate under adverse =
operational
> conditions" Quoting SCTP RFC4960: 7.  Congestion Control).
>=20
> To add level 3 QoS to the level 4 QoS we already had for WebRTC =
real-time
> traffic (NOT file transfer traffic type), the network need to see the
> traffic info in those packets and assure that those are prioritized =
instead
> of dropped at congestion in routers when fighting with file transfer =
traffic
> about the available bandwidth.=20
>=20
> If I remember correctly bit-torrent has also a setting of max =
bandwidth
> usage (maybe that is why torrent don't just use TCP's "take all you =
get" ),
> so if you have a 2 Mbps pipe, you can e.g. have bit-torrent only use =
0.5
> Mbps (no hurry to get your movie...) and leave 1.5 Mbps at least not =
harmed
> by the bit-torrent's bandwidth hunger.

Just as a data point, at least the official bit-torrent client uses a =
variant of LEDBAT ( RFC 6817 ) called uTP AFAIK, which is a mechanism =
that can better saturate a link than TCP in the absence of TCP, but is =
designed to back off fast to avoid getting in the way (by detecting =
growing queuing delay) when TCP is present.

Cheers,
Michael