I'd like to get a feel for what the temperature level
is in the ISP community for this issue -- I have a vested
[personal] interest in understanding what your understanding
& implementation plans are in this arena.
Please send your thoughts, requirements, bitches, etc., to
me personally, or preferably, to the NANOG list; it is a
greater audience than myself that wishes to understand these
issues.
Thanks!
- paul
^^^^^^^^^^^^
We need some reasonable set of knobs in the routers to manage QoS bits.
For instance, maybe if the number of packets per minute in a given flow
exceeds X ppm then QoS bits will be cranked down a notch for all packets
in that flow...
Why would we need this? Assuming that QoS can be used at no additional
dollar charge, then we need to limit its use. Or, if there is a dollar
charge associated with QoS then we still need to manage its use and to
track its use. In the dollar scenario, a customer, i.e. a company, may
wish to pay for QoS for certain uses such as two-way audio, but not for
other uses and they may wish the ISP to manage this for them.
Michael Dillon - Internet & ISP Consulting
http://www.memra.com - E-mail: michael@memra.com
The bottom line is track record. Not track tearing. Not track derailing.
But pounding the damn dirt around the track with the rest of us worms.
-- Randy Bush
If we were oversold/underprovisioned we'd be VERY interested in a way to
extort, er, extract, er, provide better quality service for a price to our
customers. 
But since we're not, QoS means little to us internally. Like nothing at
all.
Michael Dillon wrote:
We need some reasonable set of knobs in the routers to manage QoS bits.
For instance, maybe if the number of packets per minute in a given flow
exceeds X ppm then QoS bits will be cranked down a notch for all packets
in that flow...
Seems this would be easy to do in netflow switching. Also sounds a lot
like FECN/BECN in frame relay.
-peter
Sounds alot to me like sanity -- using the existing hooks
in IPv4 to deliver differentiated classes of service by using
the IP precedence bits in the TOS portion of the IP header.
- paul
Paul:
QoS/CoS Heresies:
I have enjoyed your articles in ISOC journal on QoS. As you know we are
actively looking at QoS/CoS issues here in Canada with respect to our next
generation Internet program - CA*net II.
However, I always alike to be a bit contrarian and point out that QoS or
Multicast may never be needed because of the explosive growth of fiber
bandwidth. I believe, in the future, it will be a lot easier and cheaper to
deploy bandwidth rather than manage complex router/switch technology to
support QoS/CoS.
The other issue that several studies have shown that the Internet congestion
suffered by most users is generally not due to backbone congestion, but
inadequate server facilities. So a network QoS/Cos will not solve congestion
problems as has been promised to many corporations through "business class"
Internet service offerings.
I believe that large Sonet pipes, and very shortly, all optical networks will
provide so much bandwidth on backbone networks that the need for QoS/CoS on
the backbone will be irrelevant.
The other major argument for Qos/CoS is to prevent abuse of the commons from
"power users". But usage charging either by access bandwidth, or average
load will be far more effective mechanism to prohibit abuse of the commons.
Alreasy we are seeing several OC192 networks being deployed in Canada and the
US. Most of these networks have the capacity to increase their bandwidth
with WDM and DWDM another 100 fold or 1000 fold. As well, here in Canada, we
have a couple of companies that are deploying SONET to the desktop solutions
- Positron, Skystone, JDS, etc. The nice thing about these SONET to the
desktop solution is that they emulate traditional Ethernet and Fast Ethernet
interfaces. I believe Nortel and Ciena are also building ADM's that will act
more like SONET channel switches rather than traditional ADM mux's.
I have heard rumours that Ciena and another couple WDM companies will be
delivering the first commercial all optical switches within a year or so.
These switches will initially only do channel switching, but even with that
the throughput capacity of these switches will be in the "femtabit" range.
The fastest ATM switch will pale in comparison.
The challenge for the routing and switching companies will not be to
implement QoS/CoS, but to build fast enough switches and routers to keep up
with this fire hose of data. This will have a major implication on network
design - the concept of the telco intelligent network is dead at these data
volumes. Network intelligence must move to the edge.
It for these reason, the CA*net 2 architecture features no core routers. All
of the routing functions and control of the network have moved to the edge.
Perversely, however, this ATM (or SONET) architecture has necessitated that
we buy more routers than ever!!! Now we need separate tunnel servers, Mbone
PIM servers, etc that are independent of the main edge router, because of the
significant load that edge router has to handle in this routerless core
network.!!
For more information please see the CA*net II web site at:
Bill
I believe, in the future, it will be a lot easier and cheaper to
deploy bandwidth rather than manage complex router/switch technology to
support QoS/CoS.
I disagree. With the increase in bandwidth and the rtelated increase in
multimedia applications we will need QoS/CoS in order to guarantee
bandwidth availability for email, web pages and other low bandwidth
protocols. >;-)
The challenge for the routing and switching companies will not be to
implement QoS/CoS, but to build fast enough switches and routers to keep up
with this fire hose of data. This will have a major implication on network
design - the concept of the telco intelligent network is dead at these data
volumes. Network intelligence must move to the edge.
Anyone who hasn't read Gilder's articles on the Telecosm, should take a
break now and read them http://www.seas.upenn.edu/~gaj1/ggindex.html
Michael Dillon - Internet & ISP Consulting
http://www.memra.com - E-mail: michael@memra.com
The bottom line is track record. Not track tearing. Not track derailing.
But pounding the damn dirt around the track with the rest of us worms.
-- Randy Bush