From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nm16-vm0.access.bullet.mail.mud.yahoo.com (nm16-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7E1C221F11D for ; Wed, 5 Dec 2012 06:15:17 -0800 (PST) Received: from [66.94.237.196] by nm16.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Dec 2012 14:15:12 -0000 Received: from [98.139.221.71] by tm7.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Dec 2012 14:15:12 -0000 Received: from [127.0.0.1] by smtp108.rog.mail.bf1.yahoo.com with NNFMP; 05 Dec 2012 14:15:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rogers.com; s=s1024; t=1354716912; bh=vfuBLEn9QDmdAi3RpdEXKnTswWA4USu1+J6FIBuUElI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:Reply-To:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=EDnCrnL3CS5gDVWCNmjRZcnJdsdqKubOGBeizEqb5Tb8aFnwwh4FC0QbwtjPFhqPosJhKVmdrirP079k2T+RMxiQ04BhwdZUYUfHmnN7fqzZyJF79bB4iH5mA6vq9T/WnuzkIsjuL8Mnln/yoXIoBV6EbITOHmp2jTamPHfcgsU= X-Yahoo-Newman-Id: 616391.77255.bm@smtp108.rog.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BKYa.RkVM1lQ7zZQoVXq28atpJkJTDHN.4YSrYEXhu1suOw m3PBkQ7INyqAyJ0hXOfbDG7MfMkImMRy6.IWNTWYM5l.1hHsv0i0age7T8Kx 6_ayx1WKpWlgPUg_TrskWRTqyFoVdb7FhB7ME4xJ5b6g5yi9vXnCA61FGJSH 4I8UgvSj5hsnBRPE4FDiBKtFjddg2hWXz_7i_hjCPDomqg1aLL2OQ.ydbmG4 0g_Ed5.5PTNSZDGIokMoc9dCt3mylo8Lc4AWXhk7neZChnu3sMXn1GJfhP_C NDLyYYKPY4kp9UHRuH71qhely0XSXWFtLGrxfxCzpwIaISgzbZBEkD5YS3.e JK1DA3Y.G8IrrEVIPkil2mEhXpLBUzrmFVD9tDrmssw.IlH922MlnxNxkT2a i7OYEl_NhdEQmOGki_r1L3c67NSCCbdsa2uEv6.7ibc9xp7nsYSchGuQtBnn 1330sQpEpXVFNtCQmtRWNFGPb X-Yahoo-SMTP: sltvjZWswBCRD.ElTuB1l9j6s9wRYPpuyTNWOE5oEg-- Received: from [192.168.11.44] (davec-b@216.13.131.9 with plain) by smtp108.rog.mail.bf1.yahoo.com with SMTP; 05 Dec 2012 06:15:12 -0800 PST Message-ID: <50BF57AD.8070701@rogers.com> Date: Wed, 05 Dec 2012 09:18:21 -0500 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: codel@lists.bufferbloat.net References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [Codel] Some small bits re the lwn draft article review X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: davecb@spamcop.net List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 14:15:17 -0000 After flushing what I know out of my head, I had a look at the article, and noticed a few clarifications you might want to consider for the LWN readership. In "SFQ Overview", you dive into mechanism, but you might leave the new reader behind. Instead of "With high probability, isolate “hog” sessions so that they bear the brunt of any packet dropping that might be required. To this end, ...", how about something more like "With high probability, isolate individual sessions into individual queues, ten arrange that the ones with the "hogs" bear the brunt of any packet dropping that might be required. To implement this,"... I also wonder if one would want to use "flow" instead of "session"? It does have some specific technical senses, but the general sense seems to fit well here. Further down in the same section, you note "There is also an index into this array that tracks the buckets with the most packets." I'd suggest you tie back to the motivation, and add "From this we can easily distinguish the hogs from the low-bandwidth flows." (or sessions). A but further (in para 8), you mention that SFQ is "often" configured in Linux. It might be better to say it appeared in some specific version and/or distribution at a particular date... In "FQ-CoDel Overview", para 4, you say "Nevertheless, CoDel still maintains a single queue". Since you're about to distinguish FQ-CoDel from it, I'd suggest emphasizing the variant, with "Nevertheless, the original CoDel only maintains a single queue" In "FQ-CoDel Overview", para 5, you say "packets are hashed into multiple buckets", which could be misconstrued. Perhaps it could be "packets are hashed into individual buckets" Much further on, after QQ 5, you say "This is extremely important: if there was an unending drizzle of random packets, eventually...", I simply don't get it. Could you expand a bit more here? Just before QQ 7, you write "FQ-CoDel gives users a choice between low latency and high reliability on ..". I'd suggest the user's don't get the choice, but rather the packets do, so a better phrasing might be " FQ-CoDel deals differently with low latency and high reliability flows (or sessions) on the one hand ..." In "Effectiveness of FQ-CoDel", in para 2, you define BK CS1/5 and EF in terns of what they stand for. Regrettably, the names don't say what the selectors are supposed to achieve, so the reader doesn't know which one is supposed to be the best for low latency versus high throughput, and will therefor fail to see part of the benefit of FQ_CoDel. In "Remaining Challenges", In the WiFi paragraph, you say "addressing bufferbloat in the presence of WiFi", which suggests that having WiFi on one interface or part of ones network will degrade others. Perhaps "over WiFi" would be more appropriate? --dave c-b -- 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