From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7522821F295 for ; Tue, 3 Mar 2015 23:15:16 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id la4so4945627vcb.10 for ; Tue, 03 Mar 2015 23:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JYk7l+PR7BLfVulxp1UlKmB6VZt9x0eKya7R5wJUAqQ=; b=XtIv8U6vcbUfZiBuCQNfaxzNspBOGjLaizlylKpSM6508BlzgXt4Cf4k/7wVocXyGR Pjqgjyc/Gcm4llmiYtV630gNNkZ/5IUAGSw/TxYN/hje1DuWED65j/9DzjFxyAqfU7mM psDUHSrbNz1RAzb/cG+cp7nxiJLbl+8/QCiY7boPjCSq4kxVmmwYQNxelW4GJcwUHfP7 CdiKCh2Tmp/djkrC8PwD9GT6wLrsmDq2w1TtGoM3VZPIUSRE8GekLnYxhGwl45d7FSkH Zi5wIqmYAEUerh3tbq04Ass5uLHtPjMVQ8nekDlWCJsYSa6f9//ceHm7t7Ys6Nl3vH8/ Bj+w== MIME-Version: 1.0 X-Received: by 10.52.92.39 with SMTP id cj7mr4321442vdb.97.1425453315798; Tue, 03 Mar 2015 23:15:15 -0800 (PST) Received: by 10.52.24.79 with HTTP; Tue, 3 Mar 2015 23:15:15 -0800 (PST) Received: by 10.52.24.79 with HTTP; Tue, 3 Mar 2015 23:15:15 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Mar 2015 09:15:15 +0200 Message-ID: From: Jonathan Morton To: Greg White Content-Type: multipart/alternative; boundary=bcaec5015ed1883caf051071361e Cc: sahil grover , codel@lists.bufferbloat.net Subject: Re: [Codel] why RED is not considered as a solution to bufferbloat. X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 07:15:45 -0000 --bcaec5015ed1883caf051071361e Content-Type: text/plain; charset=UTF-8 > If dequeue rate is predictable (true for some links, less so for others) then the NotCodel approach can be designed such that it will drop (or mark) *the same packets* that the CoDel approach would. In other words, in certain specific cases it is possible to behave as though you were head-dropping even though you actually aren't. And that's fine, as long as you don't forget that head-drop is the gold standard and you're just faking it. It's a general technique used in all sorts of hardware and software. But as soon as conditions change from that fairly ideal situation, you start having to genuinely do the work at the head of the queue in order to obtain the accurate sojourn times. Given the audience that I wrote that explanation for (you have seen the calibre of their questions...), I thought it best to keep away from gritty implementation details in order to keep it conceptually simple. And even on switched Ethernet - one of the more obvious candidates for the technique - the line rate can vary unexpectedly. Pause frames are the most likely cause, and one possible source of pause frames is a cable or DSL modem signalling its own link rate back to the host. But until the link is unpaused, the head packet can't be dequeued, and the sojourn time of it and any other packets behind it increases, throwing off any estimates that might have been taken at enqueue time. The likely symptoms would be similar to running normal Codel on an overbuffered Ethernet device without BQL. - Jonathan Morton --bcaec5015ed1883caf051071361e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> If dequeue rate is predictable (true for some links, le= ss so for others) then the NotCodel approach can be designed such that it w= ill drop (or mark) *the same packets* that the CoDel approach would.

In other words, in certain specific cases it is possible to = behave as though you were head-dropping even though you actually aren't= . And that's fine, as long as you don't forget that head-drop is th= e gold standard and you're just faking it. It's a general technique= used in all sorts of hardware and software.

But as soon as conditions change from that fairly ideal situ= ation, you start having to genuinely do the work at the head of the queue i= n order to obtain the accurate sojourn times. Given the audience that I wro= te that explanation for (you have seen the calibre of their questions...), = I thought it best to keep away from gritty implementation details in order = to keep it conceptually simple.

And even on switched Ethernet - one of the more obvious cand= idates for the technique - the line rate can vary unexpectedly. Pause frame= s are the most likely cause, and one possible source of pause frames is a c= able or DSL modem signalling its own link rate back to the host. But until = the link is unpaused, the head packet can't be dequeued, and the sojour= n time of it and any other packets behind it increases, throwing off any es= timates that might have been taken at enqueue time. The likely symptoms wou= ld be similar to running normal Codel on an overbuffered Ethernet device wi= thout BQL.

- Jonathan Morton

--bcaec5015ed1883caf051071361e--