From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-032-ewr.mailhop.org [216.146.33.32]) by lists.bufferbloat.net (Postfix) with ESMTP id 83EE42E0545 for ; Mon, 7 Mar 2011 10:29:53 -0800 (PST) Received: from scan-31-ewr.mailhop.org (scan-31-ewr.local [10.0.141.237]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 5CAB06F6EC5 for ; Sun, 6 Mar 2011 22:32:00 +0000 (UTC) X-Spam-Score: -1.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 74.125.82.47 Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id C99A66FD03B for ; Sun, 6 Mar 2011 22:31:54 +0000 (UTC) Received: by wwb28 with SMTP id 28so3896877wwb.28 for ; Sun, 06 Mar 2011 14:31:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PK2bztKpILdiBW8qKYJkSVdqsdzf/lgCg8TGhetz3O8=; b=waQEXIdZk3vha3ZxGqO1Fcn4hCITQpvK5LiivP2LrfqoC0FeoCw+GJVyF5tK6ZZNDQ U9didM62P2go/jUvQUGwvEmD5FRl5ef5r79ihnnP29N4+ag/MOqOVEgL9F0U3U+72aO8 EtmFYUlk9Sc2s0xKJjj2PI7f+7LLYjgFrsZ+4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kQLbAJMUjge/o394lDsiuMSYhbeCgVbfxREoBkPoJonJQbP2TWFblLH/i3wovmzQPy RMxjGPsKIydGIiZUsKrhAl9DZc6ZSy/AwAfZFo/LPWIFcawnHtzGwsrU30wJUGfURqla FW6wEfudXj8qidbuSsFe+neaAvAAtKzO6QNWc= MIME-Version: 1.0 Received: by 10.227.139.19 with SMTP id c19mr2964453wbu.13.1299450714019; Sun, 06 Mar 2011 14:31:54 -0800 (PST) Received: by 10.227.156.75 with HTTP; Sun, 6 Mar 2011 14:31:53 -0800 (PST) In-Reply-To: <7A1666CF-3E98-4668-A265-F89B50D23909@cisco.com> References: <7A1666CF-3E98-4668-A265-F89B50D23909@cisco.com> Date: Sun, 6 Mar 2011 17:31:53 -0500 Message-ID: Subject: Re: Getting current interface queue sizes From: Justin McCann To: Fred Baker Content-Type: multipart/alternative; boundary=0016e6da7da9365965049dd7f279 Cc: bloat 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:54 -0000 --0016e6da7da9365965049dd7f279 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 28, 2011 at 7:29 PM, Fred Baker wrote: > > On Feb 28, 2011, at 2:26 PM, Justin McCann wrote: > > > This may be well-known, but how does one retrieve the current outgoing > and incoming queue sizes from the link-layer interfaces? I mean the number > of packets/bytes in the various queues, not the size of the buffers > (potential queue size). I've mucked around with ethtool and netlink to grab > other statistics, but haven't found any way to pull the current queue sizes > into userspace. > > When the SNMP MIB was first developed, they originally specified ifOutQLen > as "The length of the output packet queue (in packets)." One problem: Cisco > implements that as "how many packets can I put into the queue in the deepest > possible case". The outfit I worked for before Cisco implemented it as "what > is the current depth of the output queue". Interoperable implementation... > > > There are a few issues with the "current" model. Suppose you are in this > network > ... and you ask the target what the length of its Ethernet queue is. When you > get the answer, what is the length of its Ethernet queue? > ... At the time the NMS receives the response, there's a reasonable chance that > the queue is absolutely empty. Or that it is twice as full as it was before. > Or some other number. All you can really say is that at the time the agent > answered the question, the queue had ifOutQLen packets in it. > > The object got deprecated on the grounds that it didn't make a lot of > sense. > 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. Justin --0016e6da7da9365965049dd7f279 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 28, 2011 at 7:29 PM, Fred Baker <fred@cisco.com><= /span> wrote:

On Feb 28, 2011, at 2:26 PM, Justin McCann wrote:

> This may be well-known, but how does one retrieve the current outgoing= and incoming queue sizes from the link-layer interfaces? I mean the number= of packets/bytes in the various queues, not the size of the buffers (poten= tial queue size). I've mucked around with ethtool and netlink to grab o= ther statistics, but haven't found any way to pull the current queue si= zes into userspace.

When the SNMP MIB was first developed, they originally specified ifOu= tQLen as "The length of the output packet queue (in packets)." On= e problem: Cisco implements that as "how many packets can I put into t= he queue in the deepest possible case". The outfit I worked for before= Cisco implemented it as "what is the current depth of the output queu= e". Interoperable implementation...


There are a few issues with the "current" model. Suppose you are = in this network
...=A0
and y= ou ask the target what the length of its Ethernet queue is. When you get th= e answer, what is the length of its Ethernet queue?
...=A0
At the time the NMS rece= ives the response, there's a reasonable chance that the queue is absolu= tely empty. Or that it is twice as full as it was before. Or some other num= ber. All you can really say is that at the time the agent answered the ques= tion, the queue had ifOutQLen packets in it.

The object got deprecated on the grounds that it didn't make a lot of s= ense.

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 dur= ation. 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 use= ful 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 buffe= rbloat-related per se, but I figure having the information doesn't hurt= , as long as it's not misused like you mention.

=A0=A0 =A0Justin
--0016e6da7da9365965049dd7f279--