Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Thu, Dec 15, 2005 at 07:34:56PM -0800, David Meyer wrote:
On Fri, Dec 16, 2005 at 03:29:29AM +0000, Christopher L. Morrow wrote:
On Thu, 15 Dec 2005, John Kristoff wrote:
On Thu, 15 Dec 2005 19:15:49 -0500 (EST) Sean Donelan <sean@donelan.com> wrote:
AT&T, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold QOS services for years. Level3 says 20% of the traffic over its
What do they mean by QoS? Is it IntServ, DiffServ, PVCs, the law of
I think also mostly this applies to private network things as well... which mostly ends up being: "backups get 20% of the pipe and oracle-forms gets 70%" (or some variation on that mix... what with 8 queues or whatever on the private network you can just go to town :) )
Speaking to MCI's offering on the public network it's (not sold much) just qos on the end link to the customer... It's supposed to help VOIP or other jitter prone things behave 'better'. I'm not sure that we do much in the way of qos towards the customer aside from respecting the bits on the packets that arrive (no remarking as I recall). So, what does this get you aside from 'feeling better' ?
averages or something else? I've had to deploy it on a campus network and in doing so it seems like I've tread into territory where few if any big networks are to be found. Nortel apparently removed DiffServ
most large networks (as was said a few times I think) don't really need it in their cores. I think I've seen a nice presentation regarding the queuing delay induced on 'large pipe' networks, basically showing that qos is pointless if your links are +ds3 and not 100% full. Someone might have a pointer handy for that?
You might check slides 35-38 in http://www.1-4-5.net/~dmm/sprintlink_and_mpls.ppt Dave
Hello Dave; This won't open for me. Do you have a pdf of these slides ? Regards; Marshall On Dec 15, 2005, at 10:39 PM, David Meyer wrote:
On Thu, Dec 15, 2005 at 07:34:56PM -0800, David Meyer wrote:
On Fri, Dec 16, 2005 at 03:29:29AM +0000, Christopher L. Morrow wrote:
On Thu, 15 Dec 2005, John Kristoff wrote:
On Thu, 15 Dec 2005 19:15:49 -0500 (EST) Sean Donelan <sean@donelan.com> wrote:
AT&T, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold QOS services for years. Level3 says 20% of the traffic over its
What do they mean by QoS? Is it IntServ, DiffServ, PVCs, the law of
I think also mostly this applies to private network things as well... which mostly ends up being: "backups get 20% of the pipe and oracle-forms gets 70%" (or some variation on that mix... what with 8 queues or whatever on the private network you can just go to town :) )
Speaking to MCI's offering on the public network it's (not sold much) just qos on the end link to the customer... It's supposed to help VOIP or other jitter prone things behave 'better'. I'm not sure that we do much in the way of qos towards the customer aside from respecting the bits on the packets that arrive (no remarking as I recall). So, what does this get you aside from 'feeling better' ?
averages or something else? I've had to deploy it on a campus network and in doing so it seems like I've tread into territory where few if any big networks are to be found. Nortel apparently removed DiffServ
most large networks (as was said a few times I think) don't really need it in their cores. I think I've seen a nice presentation regarding the queuing delay induced on 'large pipe' networks, basically showing that qos is pointless if your links are +ds3 and not 100% full. Someone might have a pointer handy for that?
You might check slides 35-38 in
http://www.1-4-5.net/~dmm/sprintlink_and_mpls.ppt
Dave
On Thu, 15 Dec 2005, Marshall Eubanks wrote:
Hello Dave;
This won't open for me.
Do you have a pdf of these slides ?
On Dec 15, 2005, at 10:39 PM, David Meyer wrote:
On Thu, Dec 15, 2005 at 07:34:56PM -0800, David Meyer wrote:
On Fri, Dec 16, 2005 at 03:29:29AM +0000, Christopher L. Morrow wrote:
that qos is pointless if your links are +ds3 and not 100% full. Someone might have a pointer handy for that?
You might check slides 35-38 in
those would be them.. and dave can grab just the 3 slides in pdf from: http://www.secsup.org/files/dmm-queuing.pdf (or of course anyone else can grab them, but it's dave presentation so :) ) -Chris
On Fri, Dec 16, 2005 at 03:52:20AM +0000, Christopher L. Morrow wrote:
On Thu, 15 Dec 2005, Marshall Eubanks wrote:
Hello Dave;
This won't open for me.
Do you have a pdf of these slides ?
On Dec 15, 2005, at 10:39 PM, David Meyer wrote:
On Thu, Dec 15, 2005 at 07:34:56PM -0800, David Meyer wrote:
On Fri, Dec 16, 2005 at 03:29:29AM +0000, Christopher L. Morrow wrote:
that qos is pointless if your links are +ds3 and not 100% full. Someone might have a pointer handy for that?
You might check slides 35-38 in
those would be them.. and dave can grab just the 3 slides in pdf from:
http://www.secsup.org/files/dmm-queuing.pdf
(or of course anyone else can grab them, but it's dave presentation so :) )
Thanks Chris. Dave
On Fri, 16 Dec 2005, Christopher L. Morrow wrote:
oh firstgrad spelling where ahve you gone? also at: http://www.secsup.org/files/dmm-queueing.pdf incase you type not paste.
On Fri, 16 Dec 2005 04:16:17 +0000 (GMT) "Christopher L. Morrow" <christopher.morrow@mci.com> wrote:
On Fri, 16 Dec 2005, Christopher L. Morrow wrote:
oh firstgrad spelling where ahve you gone?
also at: http://www.secsup.org/files/dmm-queueing.pdf
incase you type not paste.
Another interesting one is "Provisioning IP Backbone Networks to Support Latency Sensitive Traffic"
From the abstract,
"To support latency sensitive traffic such as voice, network providers can either use service differentiation to prioritize such traffic or provision their network with enough bandwidth so that all traffic meets the most stringent delay requirements. In the context of widearea Internet backbones, two factors make overprovisioning an attractive approach. First, the high link speeds and large volumes of traffic make service differentiation complex and potentially costly to deploy. Second, given the degree of aggregation and resulting traffic characteristics, the amount of overprovisioning necessary may not be very large ... We then develop a procedure which uses this model to find the amount of bandwidth needed on each link in the network so that an end-to-end delay requirement is satisfied. Applying this procedure to the Sprint network, we find that satisfying end-to-end delay requirements as low as 3 ms requires only 15% extra bandwidth above the average data rate of the traffic." http://www.ieee-infocom.org/2003/papers/10_01.PDF -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
participants (4)
-
Christopher L. Morrow -
David Meyer -
Mark Smith -
Marshall Eubanks