On Thu, Feb 24, 2011 at 17:37:03 +0000, Luca Bigliardi wrote:

> > I don't know how a real switch works, but I think this
> > component should aim to be as fast as possible and possibly take under
> > control every real aspect to reproduce.
> I'm not an expert in how switches/routers queuing works either, if we're
> planning to improve this we should put some effort in documenting
> ourselves. Did you consider alternative queuing systems other than
> changing the timeout parameters? For instance while designing the vde 3
> proposal we opted for a separate queuing settings for each port. The
> rationale behind this is that different ports/connections have different
> traffic capacity, hence it might be unfair to use the same timeout
> parameters for slow and fast links.

AFAIK, at least for the "average Cisco switch" on which I have had some
experience, the default behaviour is per-interface tail-drop. That is,
each egress interface has a buffer. When it's full, new packets are
dropped and there's no timeout -- enqueuing will happen again when some
old packets are delivered. Alternatives are variants of RED/WRED
algorithms, which start dropping random packets before the queue gets
full, trying to address some issues of tail-dropping especially for TCP
traffic (global synchronization is one of them).

If you go up with the price (or to layer 3 switching) you get more
refined QoS settings which are usually performed by the software (while
the tail-drop queue is handled by the hardware), but I think they're out
of scope here.

Usually, it's possible to have different policies for different ports,
but again (AFAIK) there's no "timeout". Once a packet gets assigned to
an output interface and it's enqueued, it has to be sent, either if it's
a simple hardware-based tail-drop or a complex software-handled QoS

I'm sure that this design choice (drop and never timeout) has been
initially taken for hardware simplicity reasons. I don't know if it's
still like this today because it's still the simplest thing to build or
because there's actually not much point in having timeouts in the output

<l...@dovi.co>                                        IRC: garden@freenode
OpenPGP: 1024D/63D2D5D907F89BB8         Jabber/gtalk: garde...@gmail.com

Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
vde-users mailing list

Reply via email to