That seems more like a "quadrality". :-)
> Usually, drops are seen as inefficient -- packets that
> will be dropped take up link bandwidth (a scarce resource!)
> that could be used given more careful control of buffers,
> as with credits. And credits are slammed because they
> don't do well when there are too few buffers.
In my mind there's also something vaguely disturbing about drops - or at
least consistently provoking lots of drops - because it indicates a system
where, fundamentally, senders literally have no clue, and end up sending
so fast that they shoot themselves in the foot (by dropping their own
packets and suffering timeouts) and others in the head (by filling up
buffers that others would like to use, forcing them into timeouts).
> Currently,
> if there are lots of short flows, RED will degrade to drop-tail.
Has anyone seen simulations on this? Maybe the Morris paper touched on
this? This seems like an interesting little experiment if nobody's looked
at it. Presumably it depends on the RED parameters?
> And as a final thought, one of the papers in my queue suggested
> that you don't need per-flow credits, that you can get by with
> per-destination credits, since you can multiplex together the
> packets for the same destination.
This seems interesting. Maybe the "reverse multicast tree" idea gets at
this (i can't visualize what that means), but it seems like you only get a
big win here if the "destination" is an aggregation of hosts, since a
single host will almost surely have at most 4-5 flows going to it.
neal