[e2e] Queue size of routers
dennis at juniper.net
Wed Jan 22 13:40:31 PST 2003
> Even not knowing very well how to choose it, the fact is that real life
> routers have implemented queues with a limited size.
> I think that no one believes that queues in routers are free to grow
> without limit, and that packet drops only starts when RAM space is
> So, queues do exist on actual routers, are limited in length, and
> implemented by code that was not left by an alien space ship. People who
> build the routers (like Juniper) know what they have put into their
> boxes, I presume.
I tried to answer this before in a more neutral fashion, but was perhaps
too indirect. Juniper routers use DRAM for packet buffering, so as a
consequence I think the earliest routers support about 240 milliseconds
of output buffer per port. You are free to configure smaller (or larger)
limits directly, or indirectly via RED. If you don't configure the latter
then packet drops do generally start only when RAM space is exhausted.
You could estimate the number yourself by taking the size of a DRAM chip
used by PCs, multiplying that by the number of packet reads and writes
you need to do to get a packet through the router and dividing by the
usable bandwidth of the DRAM's interface. This number has tended to
increase over time so Juniper's newer designs probably support relatively
longer output buffers still. I would be surprised if others supported
dramatically different numbers since the limitations derive from technology
issues unrelated to any actual requirement.
So while router queues are indeed limited by hardware, the hardware limits
are increasing to the point of exceeding any reasonable requirement
I can imagine for high-speed circuits and are likely to continue to
expand as time progresses, if nothing changes, so the problem really
has changed from one of what the router hardware maximally supports to
one of how you should be configuring it.
More information about the end2end-interest