From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 5578521F104 for ; Sun, 8 Dec 2013 08:26:36 -0800 (PST) Received: from hms-beagle-3.home.lan ([87.150.22.181]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LeMij-1VDL1A1mrl-00q9C5 for ; Sun, 08 Dec 2013 17:26:33 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <877gbfcw4t.wl%jch@pps.univ-paris-diderot.fr> Date: Sun, 8 Dec 2013 17:26:32 +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: Juliusz Chroboczek X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:Sa0iIcIWBUq7GlDQyNMov/W21oVfwZ6H4Yy1SMMTq6aA8jfeZey NcUTbrGJJww2tzPRJAvIpFStcBzRIYYZAbsTvE7ecN9GKa9qr6q+Lx0dtocxP28DsjNF+PE En0XlwZM0Q69OAuQ7NHQK6HGR0l2mHdLBssj/ELFFIIL64URaIOk53jxKnIG6B4ZYHK4v3z mMdWZMniqaVMdyvVuycnA== Cc: bloat 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 16:26:36 -0000 Hi Juliusz, On Dec 8, 2013, at 14:25 , Juliusz Chroboczek = wrote: >>> 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. >=20 >> 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 >=20 > 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. 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... >=20 > For throughput-sharing reasons, perhaps. For latency reasons, = hopefully not. 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. best Sebastian >=20 > -- Juliusz