From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) (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 C406F21F0AB for ; Fri, 13 Jul 2012 18:53:10 -0700 (PDT) Received: from c-24-4-217-203.hsd1.ca.comcast.net ([24.4.217.203] helo=kmnmba.local) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1SprXh-0009ey-H9; Sat, 14 Jul 2012 01:53:09 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.4.217.203 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+OBodZhD4G7MRDbTtxGPIwpZFnAZgT30U= Message-ID: <5000D10E.4070208@pollere.com> Date: Fri, 13 Jul 2012 18:53:18 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: codel@lists.bufferbloat.net References: <5000D037.7030103@pollere.com> In-Reply-To: <5000D037.7030103@pollere.com> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <5000D037.7030103@pollere.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Codel] Fwd: Re: [tsvwg] new draft on CoDel AQM 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: Sat, 14 Jul 2012 01:53:11 -0000 Fred, My reply all to your message bounced from the Cisco list...on the assumption that perhaps some of those folks are on the bufferbloat codel list, I'll forward there. Also, your points are probably of general interest. Kathie -------- Original Message -------- Subject: Re: [tsvwg] new draft on CoDel AQM Date: Fri, 13 Jul 2012 18:49:43 -0700 From: Kathleen Nichols To: Fred Baker (fred) CC: van@parc.com , buffer_bloat(mailer list) On 7/12/12 10:36 PM, Fred Baker (fred) wrote: >> 3.2. About the target value >> >> The target value constant is the maximum acceptable standing queue >> delay under a prolonged overload. Our initial focus with CoDel was >> on devices for the ordinary open internet where bottleneck >> standing queues of a few milliseconds are acceptable for ordinary >> internet traffic. We experimented with values between 1 and 20 >> milliseconds to determine a target that gives a consistently high >> utilization while controlling delay across a range of bandwidths, >> RTTs, and traffic loads. Below a target of 5ms, utilization suffers >> for some conditions and traffic loads, above 5ms we saw very little >> or no improvement in utilization. Thus target SHOULD be set to >> 5ms. > > A humble question from a mere engineer, if you please. I am an > egg... > > The Sprint paper on jitter in INFOCOMM 2004 would tend to agree with > that; within the 90th percentile, they measured variation in queuing > delay on the order of 1 ms and peaks (which they described as > "frequent") to perhaps 10 ms. They were also dealing with a 2.5 GBPS > network, arguably one of the best-engineered in the world. > > If I look at a 64 KBPS or T-1/E-1 link, which are still common > outside the broadband zone comprizing eastern Asta and ANZ, > Anglophone North America, and Western Europe, 5 ms is smaller than > the duration of a 1 MTU packet (~8*1500 = 12000 bit times). At that > point, I find myself questioning this limit. > > Question: would you object to making that be something like max(5, N > * 1000/(8 * MTU / bit rate)) ms, for some appropriate value of N? > What would you set N to? Kathleen, your simulation studies at Cisco > circa 1998 suggested 30 ms, which would be on the order of N=3... Yes, I sloppily did not put a complete discussion of target in the "about target" section. Which is why an internet draft is a "work in progress"! The first paragraph of section 3.1 does cover this, but it does need to be in 3.2. I'm proposing to add the following paragraph to section 3.2 in the next revision of this draft: "By inhibiting drops when there is less than an (outbound link) MTU worth of bytes in the buffer, CoDel adapts to very low bandwidth links. This is shown in [CODEL2012] and interested parties should see the discussion of results there. Unpublished studies were carried out down to 64Kbps." This was one of the findings that I found really exciting - this seemed to work well, but of course further studies should be carried out. But, at this point, I *would* object to the tie to "some appropriate value of N" - unless, of course, there is data suggesting otherwise. Ah. That 30ms value came from analysis backed up with simulation ...BUT...it was for a completely different approach, for "REDlight". For CoDel, I didn't see any gains in utilization above about 8ms, and the gains between 5 and 8ms were largely non-existent and not across the board. So...that was for 1998 apples, not 2012 oranges. > >> CoDel has to see sojourn times that remain above target for an >> entire interval in order to enter the drop state. > > or mark? I found ECN mentioned once in your document but not in your > pseudocode. Yes, you could mark rather than drop, but my studies didn't cover that and there will be different properties in the effect on delay. Further, for the open internet, I have concerns about the interaction of ECN traffic with non-ECN traffic and how to ensure that ECN is being used properly. So, I can't make a definitive statement on how something I didn't test will work. > >> 3.3. About the interval >> >> The interval constant is loosely related to RTT since it is chosen >> to give endpoints time to react without being so long that >> response times suffer. A setting of 100ms works well across a >> range of RTTs from 10ms to 1 second (excellent performance is >> achieved in the range from 10 ms to 300ms). For devices intended >> for the normal, terrestrial internet interval SHOULD have the value >> of 100ms. > > For very low RTT environments, such as data centers, or very high > delay environments such as multi-hop satcom, is "interval" a > configuration constant? > > Well, there are words about that in Section 5. Testing and analysis can determine appropriate settings for those circumstances. This seems to just be cross-posted to a Cisco internal list? This was not meant for IETF discussion?