From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm20-vm0.access.bullet.mail.sp2.yahoo.com (nm20-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.174]) by huchra.bufferbloat.net (Postfix) with SMTP id 57C992006AA for ; Mon, 14 May 2012 08:59:21 -0700 (PDT) Received: from [98.139.44.103] by nm20.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 May 2012 15:59:18 -0000 Received: from [98.139.44.86] by tm8.access.bullet.mail.sp2.yahoo.com with NNFMP; 14 May 2012 15:59:18 -0000 Received: from [127.0.0.1] by omp1023.access.mail.sp2.yahoo.com with NNFMP; 14 May 2012 15:59:18 -0000 X-Yahoo-Newman-Id: 427325.76537.bm@omp1023.access.mail.sp2.yahoo.com Received: (qmail 61362 invoked from network); 14 May 2012 15:59:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type; b=YjIg3zQbNCsbl+ltFgQxBon+nXu77RFjMwFm2SIgSWb70VTZps4Jk/9oQo//GSDa01aLSqhL3ohwA1S0bBF/h9Gu/v8oNdKhgi8h5Ap+Wnu5Dvno6MAo2tD8Ef3xTSW3iPxtRZaybEQgOMl7LvBkOES7qCHjC2//JfAAmvm0/94= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1337011157; bh=rXRzY/Th3q9876N7fa+9MB2ZA4qJI96ymlVCilNpmik=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type; b=Q4/2c6Jg/99JmnvwMwp2vR+SmNb/nTT9Z02lshOEdTdpoUqRxEA2sd78KZWsOcqVx+q83d6+pHbRIwcn7GOFUz3/gkzYLHFtLfUjlkN3Eoyh4ugQYioyp92sCY8HpEycGoXBHZ4nouzI+0VE9CWoROVECzc5P+2dSE75xputhhA= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3lWfLUcVM1nNeO4BdhyX_w1tIHfCbu0xo49PY6r53Jau4sd CdG7lUpOSwR5pZlXdMwBEV40zZ1YsUfBfO6EtpxJD9TUDvDtBIn3Autxusly w6rA2TCqs9zZoG9.Bl6s.Y_QOkbs746X3dftK0P6vRCPnu7hNY6ZSOT1Bxpx hh4d3aGCdoOG70Qm1mgoDucVmTWchYe.1EZ9f4h823yCV4WCw3AHHAOgsqGl ellQrXpqJRA9D3.tch5zm45fPqfqYGzZkl9gSJDNgcYCEfXymIAN5qkfHXuo LxgDucMJoMh5TdP_ul3fN4Y_M_s8A_ztL9Nh96EM66GN9UgPuLqqWfL1OqpY EoxvdS3ob2ujmcxEApT87AxKuCvQh3x3KhmXmqLKBELIyfCbizKgolH6cYRg vYLWuSnuEc_m698QQjxtmVS0iiovUBeYuAZGbsKGY X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Received: from [192.168.11.41] (davec-b@216.13.131.9 with plain) by smtp106.rog.mail.gq1.yahoo.com with SMTP; 14 May 2012 08:59:17 -0700 PDT Message-ID: <4FB12C08.1030907@rogers.com> Date: Mon, 14 May 2012 12:00:08 -0400 From: David Collier-Brown User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net X-Enigmail-Version: 1.4.1 Content-Type: multipart/alternative; boundary="------------040706080109030107060109" Subject: [Bloat] Slightly off-topic: What might be wrong with the diagrams in "Controlling Queue Delay"? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: davecb@spamcop.net List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:59:21 -0000 This is a multi-part message in MIME format. --------------040706080109030107060109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 --------------040706080109030107060109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
--------------040706080109030107060109--