> > To summarize the Peter-Sean religion on QoS: queue-reordering
> >is an EDGE function, not a CORE function. The queues in the core
> >are never long enough to make fancy-queueing worthwhile, and
> >should not even be part of the architecture once you hit
> >core-router-to-core-router speeds of 2.5Gbps.
>
> Whilst I agree that this should be true in the normal case, an
> interesting question arises in the case when links or routers have
> failed. Unless you've overprovisioned sufficiently to cope with the
> failure (how often is this done?), then you're likely to see
> significant queues build on alternate core paths. How you manage
> these queues may determine how useful your failover capability is.
A design requirement for every backbone I've worked on has been that
there is sufficent capicity to handle worst-cast single failure. When
network utilizaiton approaches the point where that is no longer possible,
it is time to increase capicity.
> The other case when you might get standing queues in the core is when
> you're suffering a DDoS attack.
Since fairly recent advent of large-scale DDoS, I've never seen standing
queues in the core, which is comprised of 2.5Gbps links. Even if this were
the case, an rare occurance such as a HUGE DDoS would not justify the
overhead associated with deploying and maintaining QOS in the core.
Andrew
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT