From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AF70921F1FA for ; Sun, 8 Dec 2013 11:21:13 -0800 (PST) Received: from hms-beagle-3.home.lan ([87.150.22.181]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MBnSJ-1Vgh5V4A4d-00ArMk for ; Sun, 08 Dec 2013 20:21:11 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 8 Dec 2013 20:21:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131203222559.GV8066@einstein.kenyonralph.com> <7ieh5pew2d.wl%jch@pps.univ-paris-diderot.fr> <87haakx1ev.wl%jch@pps.univ-paris-diderot.fr> <09D8F3A0-7172-4677-9887-119813E28740@gmx.de> <877gbfcw4t.wl%jch@pps.univ-paris-diderot.fr> To: Jonathan Morton X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:6YZrkKS9AthWjn/DTYaj9JDH1Ht/5xGyAvMwV+98AfOTYsYnnqC N8SjyPxqBScYQkECQqiOPiQpiFV1He4AMZYOGhaO/0f1OCBvAFfrCGAD9W3Bmsn/LLftGUO vLdt4VDy9HrefNFm7zSFbAHvhdRrxAtOQu96cTKkYGGOOF6BzdxWrwfWfD5QGzm5wODFj3f nFc/d1xaongvCVAWCYkoA== Cc: bloat , Juliusz Chroboczek Subject: Re: [Bloat] curious..... X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 19:21:14 -0000 Hi Jonathan, On Dec 8, 2013, at 20:01 , Jonathan Morton = wrote: > Data point: Annex M ADSL2 can be approximated as 10M down, 2M up in = practice. Throw BitTorrent at that, and round-robin delay absolutely is = relevant. ADSL1 connections will be even more so. Not everyone lives in = a city in Scandinavia. Sure, currently at adsl2+ 16M down 2.8M up, I feel the need for = a prio system to keep the telephone separated from the rest. >=20 > So a simple tiered scheme which can distinguish VoIP from BitTorrent = and both from general traffic, and applies fq_codel to each tier, is a = good idea. So have a look at /usr/lib/aqm/simple.qos, I think Dave has that = already prepared for you, all you need to do is make sure that VoIP and = BitTorrent packets are properly DiffServ labeled. Now for VoIP that = should work well, but for BitTorrent it would be nice if the router = could preemptively label those packets. (I guess most torrent clients = allow to control the number of flows and the consumed bandwidth, so = properly configured torrents would not need any special care, but who = can guarantee the "properly configured" part.) But I digress=85 Best Sebastian >=20 > - Jonathan Morton > On 8 Dec 2013 20:49, "Sebastian Moeller" wrote: > Hi Juliusz, >=20 > On Dec 8, 2013, at 14:25 , Juliusz Chroboczek = wrote: >=20 > >>> The promise of fq_codel is that we can get rid of our prioritising > >>> hacks -- if we need that kind of features, then fq_codel has > >>> failed. > > > >> Is that really true? given enough concurrent flows, critical flows > >> might be delayed purely be the round robin scheduling of equally > >> "worthy" packets in fq_codel > > > > At 100 Mbit, one full-size Ethernet frame is 120us. This means that > > if you want your VoIP traffic to have less than 30ms delay, you = should > > in principle reach your deadline as long as you have fewer than 250 > > congestion-limited flows at a given time. >=20 > Well, is 250 enough and are the 250 really realistic in a = residential setting? Currently not doing much of anything my router has = 142 active connections (according to conntrack) so 250 might be on the = low size for a device that routes multiple devices. Plus, unfortunately, = most residential internet connections are asymmetric, so on the upload = will allow fewer congestion-limited concurrent flows before the round = robin delay will impede the VOIP session. (In Germany residential VDSL = with 100Mbit/s downlink will run at 40Mbit/s uplink, so hopefully not a = big issue, but most cable providers keep the upload below 10Mbit/s, = typically 5Mbit/s for 100Mbit/s download). So we talk about an order of = magnitude fewer flows required to make phone calls "interesting". > So I still think that for VoIP prioritizing might still be = required until supplied minimum bandwidth gets higher. >=20 > > > >> so some residual priory system might still make sense... > > > > For throughput-sharing reasons, perhaps. For latency reasons, = hopefully not. >=20 > Even at 1000 symmetric I still think it would be a good idea = to isolate really latency critical traffic from the rest, even if under = normal circumstances there should be no problem, I guess a "better safe = than sorry" approach. But, hey I do not do this for a living so I might = be on the wrong track here. >=20 > best > Sebastian >=20 > > > > -- Juliusz >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat