Getting current interface queue sizes

[Justin McCann]

On Mon, Feb 28, 2011 at 7:29 PM, Fred Baker <fred at cisco.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat-devel/attachments/20110306/b2a7659a/attachment.html>