From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-02-ewr.dyndns.com (mxout-038-ewr.mailhop.org [216.146.33.38]) by lists.bufferbloat.net (Postfix) with ESMTP id D00A22E0545 for ; Mon, 7 Mar 2011 10:29:02 -0800 (PST) Received: from scan-02-ewr.mailhop.org (scan-02-ewr.local [10.0.141.224]) by mail-02-ewr.dyndns.com (Postfix) with ESMTP id 21A6A73D986 for ; Mon, 7 Mar 2011 18:29:02 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 76.96.30.32 Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mail-02-ewr.dyndns.com (Postfix) with ESMTP id 5D8DC73D802 for ; Mon, 7 Mar 2011 18:29:01 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta03.emeryville.ca.mail.comcast.net with comcast id GJQ21g00617UAYkA3JV0he; Mon, 07 Mar 2011 18:29:00 +0000 Received: from [192.168.1.119] ([98.229.99.32]) by omta13.emeryville.ca.mail.comcast.net with comcast id GJUt1g03A0hvpMe8ZJUxJe; Mon, 07 Mar 2011 18:29:00 +0000 Message-ID: <4D7523E5.3070009@freedesktop.org> Date: Mon, 07 Mar 2011 13:28:53 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: bloat-devel@lists.bufferbloat.net Subject: Re: Getting current interface queue sizes References: <7A1666CF-3E98-4668-A265-F89B50D23909@cisco.com> <24D67DE4-5637-4FFE-A375-23CF52A6BBAF@cisco.com> In-Reply-To: <24D67DE4-5637-4FFE-A375-23CF52A6BBAF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 18:29:03 -0000 On 03/07/2011 02:21 AM, Fred Baker wrote: > > On Mar 6, 2011, at 2:31 PM, Justin McCann wrote: > >> Thanks for your response. This is more research-related, trying to detect what parts of the stack on an end host are exhibiting and/or causing network stalls a few RTTs or more in duration. I'm also watching the number of bytes and packets sent/received, and when activity stops altogether, looking at the queue sizes shows where things are getting held up. I don't think the approach would be as useful for a middlebox that is just doing best-effort forwarding, but it would probably work if the box was acting as a TCP proxy. So, it's not bufferbloat-related per se, but I figure having the information doesn't hurt, as long as it's not misused like you mention. > > No doubt. But I think you'll find that Cisco equipment tells you the maximum queue depth, not the current queue depth, or doesn't implement the object. > Cisco is far from unique. I found it impossible to get this information from Linux. Dunno about other operating systems. It's one of the things we need to fix in general. Exactly what the right metric(s) is (are), is interesting, of course. The problem with only providing instantaneous queue depth is that while it tells you you are currently suffering, it won't really help you detect transient bufferbloat due to web traffic, etc, unless you sample at a very high rate. I really care about those frequent 100-200ms impulses I see in my traffic. So a bit of additional information would be goodness.g - Jim