Fred -
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. Peter Lothberg
has excellent slides comparing the line utilization vs queueing
delay for various line-speeds, incidentally.
However, there are lots of edges to the network, and
indeed there are entirely separate networks which are constructed
out of only low-bandwidth bottlenecks in front of which one frequently
observes packet queues. QoS is just fine there, architecturally.
However, my feeling on pricing out edge QoS is that it should
cost you money to have a provider do fancy-queueing for
you, and that the price ought to be closely related to the price of
upgrading the bottleneck to the point that there is on average no
queueing in the provider->customer direction.
Likewise, my feeling on {diff,int}-serv is that core
providers who have zero average length queues (i.e., ones
with ample bandwidth) should simply be "QoS transparent",
and simply never interpret the packet markings or participate
in QoS negotiations: those mechanisms are not worth it unless
it lets one extract more cash from a customer who is unable
to upgrade his or her bottleneck (e.g., they are stuck with
only a monopoly local loop provider who won't deliver an
upgrade). So far there is no evidence that the revenue
uplift would ever come close to the maintenance costs...
This should be taken into account in proposals in which
QoS negotiations are subsumed by the routing system.
Sean.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT