From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3BC4C2022C1 for ; Mon, 14 May 2012 09:27:23 -0700 (PDT) Received: by qadb33 with SMTP id b33so4082362qad.16 for ; Mon, 14 May 2012 09:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VRHi4ma465wN3wyO3Q5FLJ8oWr4JSyAjMi1s0nggMS8=; b=KBGtX1LZXBnUbBL8kp6pKXmGfqPssM8aEd52I0ODTm+WtRcNEGUUzqX1S02l6y05a0 MOTfcMp7AmWAzGDwiZTfbN70c/v1Glj9Tde33kTvdGcXPUb3KmQm5MWT3lMBukmvgrTC DDxiwnhRRk7lc1rRC6opdrP63B7aXxU5Eq7FZdJL6h7RamwbteJUmLrVM5lTb5PfsBV3 Co2ZRkN9qWYplbsmdVTa8LfPcACh4C6TULi4ee0wiy1Wa/za/IcMfOTT28kjJe6tO36T AS4GJ/3QEUDTnQAzqR9pLkHJFH9N8zV7Czb7qwWR/m15iMoWDW61TyZ3FgFlusft7rla NaLQ== Received: by 10.229.135.7 with SMTP id l7mr4350723qct.20.1337012841581; Mon, 14 May 2012 09:27:21 -0700 (PDT) Received: from [10.9.0.119] ([207.228.237.150]) by mx.google.com with ESMTPS id ch15sm40359884qab.18.2012.05.14.09.26.10 (version=SSLv3 cipher=OTHER); Mon, 14 May 2012 09:27:20 -0700 (PDT) Sender: Jim Gettys Message-ID: <4FB1321D.3070500@freedesktop.org> Date: Mon, 14 May 2012 12:26:05 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: davecb@spamcop.net References: <4FB12C08.1030907@rogers.com> In-Reply-To: <4FB12C08.1030907@rogers.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: David Collier-Brown , "codel@lists.bufferbloat.net" Subject: Re: [Codel] [Bloat] Slightly off-topic: What might be wrong with the diagrams in "Controlling Queue Delay"? 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: Mon, 14 May 2012 16:27:23 -0000 David, There is a codel@lists.bufferbloat.net list these days, where both Kathie and Van hang out among others. I don't know if they are subscribed to the bloat@lists.bufferbloat.net list. - Jim On 05/14/2012 12:00 PM, David Collier-Brown wrote: > Management Summary > > In figures 5 and 6, the eye can't see the trend. 8 and 9 aren't as > bad, but it would be A Good Thing to make the trend explicit. > > > In a blog discussion with Jim Gettys, I noted that at least two of the > figures in /Controlling Queue Delay,/ by Kathleen Nichols and Van > Jacobson, were mysteriously unclear. Jim, not unexpectedly, asked > me to be specific (:-)) > > This was hard because I had no idea /why/ I had reacted so badly to > two diagrams which I understood. After a considerable time, I realized > what was wrong:I knew what the diagrams were about! Thus this > message, to see if the community saw the same thing. I've written it > as if I were addressing Van Jacobson... > > I knew that 5A, 6A and 7A were all comparisons of delay versus load, > so I understood that they should have the form I saw. I already > expected CoDel to be "better", so I expected the diagrams to > illustrate that. > > However, if I had not already known what to expect, the diagrams would > have been much less clear. Two things would have stood out > > 1. The trend as the bandwidth increased would not have been obvious > 2. The behaviour of RED would have looked better than that of CoDel. > > > When I look at any of the "A" diagrams without preconceptions, I see > two separate pairs of data, separated by a blank space. To my eyes, > that looks like there is something to compare between each of the data > in those pairs, or perhaps between the pairs. This is wildly different > from what the diagrams seek to illustrate! They really describe a > curve, with known margins of error, relating packet delay to > bandwidth. That's a continuous curve, not four disparate points. > > It's unclear why there should be only four points: with this spacing, > there arguably should be eight, to make the diagram look continuous. > Since it's non-linear, perhaps one should consider making the X axis > logarithmic? > > In fact, it's unclear why there should be points at all and not > lines. The useful information is that delay falls in a non-linear > fashion as bandwidth increases. The box plots tell me about the margin > of error, and therefor suggest to me that the margin of error's > important. After all, that's what's emphasized! [I had a 5A.gif here] > > To make the trend important, it needs to be emphasized. A curve drawn > through the medians would probably suffice, but explicitly drawing the > diagram as a "river" the width of the box, plus a center-line, would > be much clearer. {I had a pair of pencil-sketches here] > > Finally, when comparing RED to CoDel, it's best to plot them both on > one graph, so one can see the improvement, and not have to mentally > subtract one diagram from another. > > The second consideration is that the diagrams give the the impression > that RED is better, as it yields less delay at every point except 3 > MB/S. Somehow, that seems the very**/opposite/** of what we're trying > to demonstrate. Are these values reversed? If not, do they support our > thesis that CoDel is better, or should we seek a better metric? > > Similarly, all the "B" diagrams need at least a trend line drawn. > Fortunately the CoDel results are clearly better than RED's when > considering utilization. > > Figures 8 and 9 are much better at illustrating the trend of each of > their data, but could use at least a trend line, if not a redrawing > into "rivers". > > Figure 7 I simply skipped over: the others were puzzling enough to the > eye that I deferred trying to puzzle it out until now. > > To accompany this, even for an audience of mathematicians, the body of > the article should say what the diagrams are intended to demonstrate, > and why that information supports the thesis of the article. > > Now, just so you don't think you've blown everything, figures 1 and 2 > clearly illustrate what the text describes, and shows a practitioner > how this change fixes the "bufferbloat" problem. They're really > rather brilliant*, and allow the reader to understand how the fix works. > > If they were the only thing the article had shown, it would still have > made its point. > > --dave > [* I'm a Canadian, and engage in understatement (:-)] > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > davecb@spamcop.net | -- Mark Twain > (416) 223-8968 > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat