Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
One thing to note here is that while VoIP flows are low volume on a bits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow. And I have seen cases of older line cards approaching their pps limits when handling large numbers of VoIP flows even though there's plenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. -C On Dec 16, 2005, at 4:29 AM, [EMAIL PROTECTED] wrote: A single VoIP call is a rather slim volume of packets compared to many other uses of the Internet. If a network doesn't have systemic jitter caused by layer 2 congestion, then one would expect VoIP to work fine on a modern network. Indeed, that is what Bill Woodcock reported a year or so ago in regard to INOC-DBA. --Michael Dillon
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Chris Woodfield wrote: One thing to note here is that while VoIP flows are low volume on a bits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow. And I have seen cases of older line cards approaching their pps limits when handling large numbers of VoIP flows even though there's plenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. -C In that vein, and not quite on this topic, it would be real nice if voip applications made an effort to stop abusing networks with unneccessarily large pps. Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On 18/12/05, Chris Woodfield [EMAIL PROTECTED] wrote: One thing to note here is that while VoIP flows are low volume on abits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow.And I have seen cases of older line cards approaching their ppslimits when handling large numbers of VoIP flows even though there'splenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. Only older line cards ? Currently NPE-G1'sare causing me more headaches in that regard. At least up until last friday. /Tony
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Joe Maimon wrote: Chris Woodfield wrote: One thing to note here is that while VoIP flows are low volume on a bits-per-second basis, they push substantially more packets per kilobit than other traffic types - as much as 50pps per 82Kbps flow. And I have seen cases of older line cards approaching their pps limits when handling large numbers of VoIP flows even though there's plenty of throughput headroom. That's not something LLQ or priority queueing are going to be able to help you mitigate at all. -C In that vein, and not quite on this topic, it would be real nice if voip applications made an effort to stop abusing networks with unneccessarily large pps. VoIP by design will have high PPS per connection as opposed to data flows. At 20 ms sample rates you have 50 pps regardless of the CODEC or algorithm. Increasing the time per sample to 40 ms would cut this in half but the added latency would result in degraded quality. In addition, longer sample times would suffer much more degradation if there is packet loss. Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput. I'm not sure why you say the payload length has much to do with RTT. Serialization delay on slow edge links could increase RTT, but this would worsen substantially with longer samples (assuming the same CODEC and compression). Payload length is a factor of the sample length and compression algorithm. More efficient compression will result in smaller payloads but overhead becomes a higher percentage of the overall flow. Only lengthier samples will reduce PPS, and the added latency in a two-way conversation will substantially reduce call quality. -- Jay Hennigan - CCIE #7880 - Network Administration - [EMAIL PROTECTED] NetLojix Communications, Inc. - http://www.netlojix.com/ WestNet: Connecting you to the planet. 805 884-6323
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Sun, 18 Dec 2005, Joe Maimon wrote: Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput. What is your suggestion? High latency connections can have higher VOIP latency by increasing packet size, or low IP-latency connections can handle higher VOIP latency by increasing packet size? -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Jay Hennigan wrote: VoIP by design will have high PPS per connection as opposed to data flows. At 20 ms sample rates you have 50 pps regardless of the CODEC or algorithm. Increasing the time per sample to 40 ms would cut this in half but the added latency would result in degraded quality. In addition, longer sample times would suffer much more degradation if there is packet loss. My point is that sampling length should take into effect the rtt. A rtt of 200ms tolerates far shorter sampling slices than does 20ms.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Mikael Abrahamsson wrote: On Sun, 18 Dec 2005, Joe Maimon wrote: Something about intelligent edges? The payload length of voip applications often has a lot to do with rtt. Adapting payload length to the actuall average rtt could have a positive effect on pps throughput. What is your suggestion? High latency connections can have higher VOIP latency by increasing packet size, or low IP-latency connections can handle higher VOIP latency by increasing packet size? The latter.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005, Christopher L. Morrow wrote: ah-ha! and here I thought they wanted buzzword compliance :) From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else. When you're running voip over a T1/E1, you really want to LLQ the VOIP packets because VOIP doesn't like delay (not so much a problem) nor jitter (big problem), nor packetloss (not so much a problem if it's less than a 0.1 percent or so). So combining voip and data traffic on a link that sometimes (more often now when windows machine have a decent TCP window) go full, even just in a fraction of a second, means you either go QoS or do what Skype does, crank up the jitter buffer when there is high-jitter, which means latency for the call goes up. So prioritizing packets in the access and core is good, for access because it's usually low-bandwidth and going to higher bw to remove congestion might mean factor 10 higher bw and a serious cost, in the core it's good to handle multiple faults, if the things that never should happen, you're not dropping your customers VOIP packets when the pipe is full that 0.1% of the time. But, if you take the above model and start to always run your pipes full and use core packet prioritization as an everyday thing to support your lack of core bw, then you're in much bigger doo-doo. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
Yes. Best effort should be something to aspire to, not worse than carrier grade -Original Message- From: Sean Donelan[EMAIL PROTECTED] Sent: 16/12/2005 00:15:49 To: nanog@merit.edunanog@merit.edu Cc: Subject: RE: The Qos PipeDream [Was: RE: Two Tiered Internet] On Thu, 15 Dec 2005, Fergie wrote: I think Bill Manning hit on it a couple of days ago; Bill said something about the Internet being about best effort and QoS should be (various) levels of 'better-than-best effort' -- and anything less that best effort is _not_ the Internet. [truncated by sender]
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005 04:16:17 + (GMT) Christopher L. Morrow [EMAIL PROTECTED] wrote: On Fri, 16 Dec 2005, Christopher L. Morrow wrote: http://www.secsup.org/files/dmm-queuing.pdf 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
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
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? Here in London, we have noticed that the double-length bendy buses have a harder time moving through city streets than motor scooters do. I suspect that the studies you are referring to show that the key factor is the ratio between the size of pipe and the size of the flows moving through that pipe. diffserv is the devil... and I think the voip product(s) in question aren't meant to be used in places where bandwidth is the constraint :) A single VoIP call is a rather slim volume of packets compared to many other uses of the Internet. If a network doesn't have systemic jitter caused by layer 2 congestion, then one would expect VoIP to work fine on a modern network. Indeed, that is what Bill Woodcock reported a year or so ago in regard to INOC-DBA. --Michael Dillon
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Thus spake Mikael Abrahamsson [EMAIL PROTECTED] On Fri, 16 Dec 2005, Christopher L. Morrow wrote: ah-ha! and here I thought they wanted buzzword compliance :) From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else. When you're running voip over a T1/E1, you really want to LLQ the VOIP packets because VOIP doesn't like delay (not so much a problem) nor jitter (big problem), nor packetloss (not so much a problem if it's less than a 0.1 percent or so). There's two problems, actually. The first is serialization delay, and afflicts any link under about 3Mb/s regardless of utilization. Access speeds are finally climbing past this, but for links where they haven't you need something like MLPPP for fragmentation and interleaving. The second is queueing delay, and that tends to only matter when average utilization passes 58% (someone with a stat background explained why, but my math isn't good enough to explain it). LLQ and WRED solve this well enough for end systems to cope with the result. So combining voip and data traffic on a link that sometimes (more often now when windows machine have a decent TCP window) go full, even just in a fraction of a second, means you either go QoS or do what Skype does, crank up the jitter buffer when there is high-jitter, which means latency for the call goes up. Adaptive jitter buffers are old technology; Skype is hardly the first company to use them. Most phones and softphones have them; it's the gateways at the other end that are usually stuck with static ones. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005, Stephen Sprunk wrote: Adaptive jitter buffers are old technology; Skype is hardly the first company to use them. Most phones and softphones have them; it's the gateways at the other end that are usually stuck with static ones. Personally I find the delay of the mobile phones (200ms or so) annoying enough and with just a static 40ms buffer you end up with 80ms of RTT in the jitterbuffer alone, adding some access technologies like SHDSL or alike it's easily over 100ms, compared to less than 20-30ms for a regular call within a region. I am not a QoS buff, but it packet prioritization does have it's place, even if it's only WFQ. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005, Min Qiu wrote: Hi Chris, hey :) -Original Message- From: [EMAIL PROTECTED] on behalf of Christopher L. Morrow Sent: Thu 12/15/2005 10:29 PM To: John Kristoff Cc: nanog@merit.edu Subject: Re: The Qos PipeDream [Was: RE: Two Tiered Internet] snip... 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' ? Not 100% true. Through I agree QoS has little impact in the core that has OCxx non-congested backbone (more comments below). In the edge, it does has its place, as Stephen Sprunk and Mikael Abrahamsson explained/described. I recalled we were busy at one time to find out why one of our _most_ important T1 customer's poor VoIP performance. It turned out his T1 was peaked in those peroid. yup, for t1 customers (or dsl or dial) qos matters only if your like is full when you want to do something with stringent delay/jitter/loss requirements (voip). Possibly a better solution for both parties in the above case would have been MLFR ... possibly. (someone would have to run the numbers, I'm not sure how much the 'qos' service costs in real $$ not sales marked-down-for-fire-sale $$) snip... 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? There is a little problem here. Most of the studies assume packet arrive rate governed by poision rule. Those data collections were from application sessions--normal distribution when number of sessions--infinity. However, this can only apply to core, specially two tiered core where packet arrive rate are smoomthed/aggregated. I did experied long delay on a DC3 backbone when the utilization reach to 75%~80%. Packet would drop crazy when the link util reach to ~90% (not 100% tied to quenueing, I guessed). That said, i think this is where WRED is used... avoid the sawtooth effect of tcp sessions, random drop some packets and force random flows to backoff and behave. I think I recall WRED allowing (with significant number of flows) usage to reach 95+% or so smoothly on a ds3... though that is from some cisco marketting slides) it only move the threahold in the core from DC3 to OC12 or OC48 (see Ferit and Erik's paper Network Characterization Using Constraint-Based Definitions of Capacity, Utilization, and Efficiency (http://www.comsoc.org/ci1/Public/2005/sep/current.html I don't have the access). I'm not sure the study can applied to customer access edge where traffic tend to be burst and the link capacity is smaller in general. Maybe part of the discussion problem here is the overbroad use of 'QOS in the network!' ? Perhaps saying, which I think people have, that QOS applied to select speed edge interfaces is perhaps reasonable, I'd bet it still depends on the cost to the operator and increased cost to the end-user. it may be cheaper to get a second T1 than it is to do QOS, and more effective. Alternately, customers could use other methods aside from QOS to do the shaping, assuming 'QOS' is defined as tos bit setting and DSCP-like functions, not rate-shaping on protocol or port or source/dest pairs.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Wednesday 14 December 2005 23:31, Randy Bush wrote: would we build a bank where only some of the customers can get their money back? Not taking into account the FDIC, we already have that, since banks are only required to keep 10% of any given depositor's monies. we're selling delivery of packets at some bandwidth. we should deliver it. otherwise, it's called false advertising. No, it's called oversubscription, and it is what produces busy signals/dropped packets/ slow response. What ISP doesn't oversubscribe consumer capacity? When the full cost of that packet at that speed is not passed along to the customer, then the only way for the ISP to remain viable (currently) is to oversubscribe. The same occurs at the telco for POTS. The whole QoS angle is just a way to get people to pay for something they think is better, but is really no different in practice. (Fergie's smoke and mirrors). So in essence there is already a 2 tier Internet, as has been said: consumer-grade (oversubscribed), and real (1:1 bandwidth subscription). Real means that if you buy a T1 or an OC3 or whatever, you get what you paid for, to your ISP's PoP. Consumers don't get this; they get a burst bandwidth at the burst rate, but there is no committed rate for consumers. Otherwise I could get an OC-3 full rate for $1,500 per month (in the boonies, no less). Where problems arise is when those who think they are getting 1:1 real Internet (really just a pipe to their ISP) are actually getting oversubscribed bandwidth instead of 1:1. While marketing seems to be just short of sacrilege to many here, the fact is that NOC personnel salaries have to be paid from somewhere, and if your business is selling bandwidth, then your revenue from customers minus cost of said bandwidth minus operational expenses (salaries, capital, power, etc) had better result in a quantity that is greater than zero, or you're going to be unemployed rather soon. If you are selling $50 6Mb/s DSL, and you're paying $10 per Mb/s, then you have a problem, and oversubscription is your solution. Oversubscribing 4 to 1 makes your non-oversubscribed $240 per month for four subscribers for your bandwidth cost only $60 per month, and you now have $140 per month to pay your NOC personnel and turn a profit (or at least break even). The local ISP here is only oversubscribed two to one; I don't see how they are making any money at all, even with fairly high DSL cost, as I've seen the kind of prices their upstream charges for 1:1 rates. Of course, your upstream (if you have one) also has to make their ends meet, too. At the top SFI level, you still have the cost of transit to worry about, with $1,000 per year or more per mile for fiber maintenance; if you have 25,000 miles of fiber you need to generate $25 million per year to keep it maintained, even if you don't have an upstream. Of course, the $35,000 per mile for fiber installation has to be amortized, too, as does that $2 million backbone router on each end of every hop, etc. Bandwidth has to have a cost; otherwise the bandwidth provider will not stay around long. On the operational end, the challenge becomes designing networks that in the presence of ubiquitous oversubscription degrade gracefully and allow certain features to have lesser degradation. Thus QoS. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Thus spake Christopher L. Morrow [EMAIL PROTECTED] On Fri, 16 Dec 2005, Min Qiu wrote: Not 100% true. Through I agree QoS has little impact in the core that has OCxx non-congested backbone (more comments below). In the edge, it does has its place, as Stephen Sprunk and Mikael Abrahamsson explained/described. I recalled we were busy at one time to find out why one of our _most_ important T1 customer's poor VoIP performance. It turned out his T1 was peaked in those peroid. yup, for t1 customers (or dsl or dial) qos matters only if your like is full when you want to do something with stringent delay/jitter/loss requirements (voip). Possibly a better solution for both parties in the above case would have been MLFR ... possibly. (someone would have to run the numbers, I'm not sure how much the 'qos' service costs in real $$ not sales marked-down-for-fire-sale $$) MLFR (you mean FRF.8?) works, but you first need to learn how to do FRTS, which is a nightmare in itself. MLPPP LFI is trivial to set up. However, MLFR/MLPPP only help when paired with an intelligent queueing algorithm; with FIFO and even WFQ they're useless. You've gotta go to CBWFQ/LLQ to get the benefits. it only move the threahold in the core from DC3 to OC12 or OC48 (see Ferit and Erik's paper Network Characterization Using Constraint- Based Definitions of Capacity, Utilization, and Efficiency (http://www.comsoc.org/ci1/Public/2005/sep/current.html I don't have the access). I'm not sure the study can applied to customer access edge where traffic tend to be burst and the link capacity is smaller in general. Maybe part of the discussion problem here is the overbroad use of 'QOS in the network!' ? Perhaps saying, which I think people have, that QOS applied to select speed edge interfaces is perhaps reasonable, I'd bet it still depends on the cost to the operator and increased cost to the end-user. it may be cheaper to get a second T1 than it is to do QOS, and more effective. For some scenarios, yes, but in most environments the peaks would still fill the pipes, just for half the time. And, as we all know, the faster the network gets, the more creative ways people find to fill those pipes. It's a rat race, but your telco salescritter will love you for it. Overprovisioning the last mile is, at least for now, far more expensive than training a monkey to apply a cookie-cutter MLPPP/LLQ config; from the comments here, consensus is the opposite is true in the core. My experience is with large-but-slow networks (thousands of sub-T1 sites) so I can't say how true that is, but it sounds right. Alternately, customers could use other methods aside from QOS to do the shaping, assuming 'QOS' is defined as tos bit setting and DSCP-like functions, not rate-shaping on protocol or port or source/dest pairs. QoS has lots of different meanings, thanks to the marketeers. The one most customers think of, and the only one that's provably wrong, is QoS is a magic wand that gives you free bandwidth. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005, Christopher L. Morrow wrote: Maybe part of the discussion problem here is the overbroad use of 'QOS in the network!' ? Perhaps saying, which I think people have, that QOS Probably. Users, executives and reporters are rarely careful talking about the technical details. They are usually more interested solving a problem. Engineers sometimes get caught up in arguing about the pro's and con's of a particular widget and sometimes miss other ways to solve the real problem. Suppose you wanted your web content to load faster on a user's computer, how would you do it? Could you hire a content distribution network like Akamia to improve the quality of service for your content? Is the Internet a zero-sum game, so if Akamia makes one web site faster does that mean all other web sites must get slower? Instead of paying a CDN, what if an ISP told content providers you could host your content on our server farms close to the end-user connections. If the content provider doesn't pay the ISP to host the content on their network, the content is delivered over the Internet from wherever in the world the content provider data center is located. There are lots of ways to improve the quality of service for some content versus other content. Should ISPs be prohibited from giving a CDN operator space or bandwidth for its servers because they don't have space for every CDN that wants space? Should ISPs be prohibited from operating their own CDN? Doesn't a CDN create an unlevel playing field between content providers that pay to use it over content providers that don't pay for the CDN? If you want to define QoS as a strawman, you can. But it doesn't solve the problem.
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
Sean, And let's see: What was the problem again? ;-) Oh, yeah -- some telco execs want to degrade traffic in their networks based on __. (Fill in the blank.) - ferg -- Sean Donelan [EMAIL PROTECTED] wrote: On Fri, 16 Dec 2005, Christopher L. Morrow wrote: Maybe part of the discussion problem here is the overbroad use of 'QOS in the network!' ? Perhaps saying, which I think people have, that QOS [snip] If you want to define QoS as a strawman, you can. But it doesn't solve the problem. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
Bingo. Very well stated. - ferg -- Lamar Owen [EMAIL PROTECTED] wrote: [snip] On the operational end, the challenge becomes designing networks that in the presence of ubiquitous oversubscription degrade gracefully and allow certain features to have lesser degradation. Thus QoS. [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
Randy- I don't think your bank analogy is very strong, but never mind that. I agree with what you're saying in principle, that if a user/customer buys bit delivery at a fixed rate then we should deliver it. But as ISPs we don't sell this. As a network operator, I do sell various kinds of point-to-point connections with fixed/guaranteed rates. But when I sell Internet, or L3VPN, etc., I'm selling end-to-end packet-switched full-mesh connectivity. In this service, not all endpoints are equal and traffic patterns are not fixed. I.e., the service is flexible. QoS is about giving the customer control over what/how traffic gets treated/dropped. It's not false advertising. That said, if QoS controls are used to enforce the provider's preferences and not the customers' then I might agree with the false advertising label. If the result is to have anti-competitive effects then I might have some harsher labels for it, too. Cheers, -Benson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Randy Bush Sent: Wednesday, 14 December, 2005 22:32 To: Hannigan, Martin Cc: Fergie; nanog@merit.edu Subject: RE: The Qos PipeDream [Was: RE: Two Tiered Internet] Can we build, pay for, and sustain an Internet that never has congestion or is never busy. s/never/when there are not multiple serious cuts/ would we build a bank where only some of the customers can get their money back? we're selling delivery of packets at some bandwidth. we should deliver it. otherwise, it's called false advertising. randy
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
Randy- I don't think your bank analogy is very strong, but never mind that. I agree with what you're saying in principle, that if a user/customer buys bit delivery at a fixed rate then we should deliver it. But isn't that the point. You can't guarantee delivery, just as you can't guarantee you won't get a busy signal when you make a call. -M
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
If the core is well run (not normally over-utilized) and the endpoints have adequate capacity, then you *can* guarantee the call. (where guarantee represents a quality *approaching* 100%, as defined in SLAs...) I assume we're not talking about poorly-run cores here. So what I think you're getting at is, when you don't control both endpoints (i.e., to ensure they have adequate capacity) then you can't make end-to-end guarantees. This is clearly true, in telephone networks as well as packet networks. But it doesn't lessen the value of QoS mechanisms. To reluctantly further the telephone analogy: If all 23 bearers on my PRI are busy I still might want to allow certain sources to complete calls to me, even if that means dropping an existing call. This is a local function that I can guarantee, which benefits end to end communication even if it doesn't guarantee it. And if I coordinate this local function at both endpoints then I'm back to my first statement, that you can guarantee end to end. Are you suggesting that QoS has no value unless it can do more than this? Or am I misunderstanding you? A more interesting question is how to make end-to-end guarantees between endpoints that are on different cores, assuming the endpoints themselves are under a common control. If the provider overrides customer QoS preferences, is this possible? Cheers, -Benson -Original Message- From: Hannigan, Martin [mailto:[EMAIL PROTECTED] Sent: Thursday, 15 December, 2005 16:00 To: Schliesser, Benson; Randy Bush Cc: nanog@merit.edu Subject: RE: The Qos PipeDream [Was: RE: Two Tiered Internet] Randy- I don't think your bank analogy is very strong, but never mind that. I agree with what you're saying in principle, that if a user/customer buys bit delivery at a fixed rate then we should deliver it. But isn't that the point. You can't guarantee delivery, just as you can't guarantee you won't get a busy signal when you make a call. -M
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On 12/15/05, Hannigan, Martin [EMAIL PROTECTED] wrote: But isn't that the point. You can't guarantee delivery, just as you can't guarantee you won't get a busy signal when you make a call. Absolutely. But if the carrier tunes their network so you will never get a busy signal when calling into 900 numbers from which they receive a kickback (hosted on their network or just preferred partners), at the cost of a greater likelihood of busy signals for calls which are not as profitable for them, this is enforcing the provider's preferences and not the customers. When carriers start to tune their network so not only do VOIP connections to their own servers get a higher QoS, but also in a manner which tends to *induce* jitter and other 'Q'uality degradation for Skype and Vonage, then it's time for them to lose common carrier protection. Kevin Kadow -- Disclaimer: I no longer am a contractor for SBC, nor any _for-profit_ ISP.
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
Hi Benson, Okay -- forget about banks, forget about other comparative analogies -- let's talk about the Internet. I think Bill Manning hit on it a couple of days ago; Bill said something about the Internet being about best effort and QoS should be (various) levels of 'better-than-best effort' -- and anything less that best effort is _not_ the Internet. I completely agree with this, and I would also add that anything less than best effort is not a QoS frob, it is penalization, no matter what you want to call, and is a Bad Thing (tm). I really don't want to get into a debate on service-level semantics (e.g. WRED, etc.) but I think most reasonable people can understand what I'm trying to illustrate. This thread has gone one far enough as it stands. :-) I think that the knobs are already 'out there' for service providers, etc. to create real 'services', but to create arbitrary services just to protect one's walled garden, and/or to generate revenue (while also penalizing some customers) is something that the market will have to sort out. It always does. Vote with your dollar$. Cheers, - ferg ps. Having looked at QoS issues from the inside-out, outside-in, and various other persepctives, I do know a thing or two about it. :-) -- Schliesser, Benson [EMAIL PROTECTED] wrote: Randy- I don't think your bank analogy is very strong, but never mind that. I agree with what you're saying in principle, that if a user/customer buys bit delivery at a fixed rate then we should deliver it. But as ISPs we don't sell this. As a network operator, I do sell various kinds of point-to-point connections with fixed/guaranteed rates. But when I sell Internet, or L3VPN, etc., I'm selling end-to-end packet-switched full-mesh connectivity. In this service, not all endpoints are equal and traffic patterns are not fixed. I.e., the service is flexible. QoS is about giving the customer control over what/how traffic gets treated/dropped. It's not false advertising. That said, if QoS controls are used to enforce the provider's preferences and not the customers' then I might agree with the false advertising label. If the result is to have anti-competitive effects then I might have some harsher labels for it, too. Cheers, -Benson [snip] -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Thu, 15 Dec 2005, Fergie wrote: I think Bill Manning hit on it a couple of days ago; Bill said something about the Internet being about best effort and QoS should be (various) levels of 'better-than-best effort' -- and anything less that best effort is _not_ the Internet. ATT, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold QOS services for years. Level3 says 20% of the traffic over its backbone is better than Best-Effort. Ok, maybe they aren't the Internet. Internet2 gave up on premium QOS and deployed less-than Best Effort scavenger class. Ok, may they aren't the Internet either. I think that the knobs are already 'out there' for service providers, etc. to create real 'services', but to create arbitrary services just to protect one's walled garden, and/or to generate revenue (while also penalizing some customers) is something that the market will have to sort out. It always does. Vote with your dollar$. Ah, good to see that you agree with Bill Smith from BellSouth. William Smith, chief technology officer at BellSouth, argues that competitive forces, rather than regulation, are all that's needed to prevent the totalitarian online environment that the web camp fears. We have no intention whatsoever of saying 'You can't go here, you can't go there, you can't go somewhere else', Smith said. We have a very competitive situation with cable. If we start trying to restrict where our customers can go on the internet, we would see our DSL customers defect to cable in droves. But, he added, If I go to the airport, I can buy a coach standby ticket or I can buy a first class ticket from Delta. I've made a choice as to which experience I want. But also realize all companies are acting in their own self-interest, even the companies that have hire lobbyists claiming to be saving the Internet. The enemy of your enemy isn't always your friend. I agree QOS as defined by marketeers isn't very useful. But that is a strawman argument. Of course, I understand you think its just politics. On the other hand, those same QOS tools are very useful to the network engineer for managing all sorts of network problems such as DOS attacks and disaster recovery as well as more efficiently using all the available network paths. I have no idea how all this will turn out or if there are some dark smoke-filled rooms somewhere I don't know about where the henchmen are plotting. But I would really hate to see the network engineer's hands tied by a law preventing them from managing the network because of some people spreading a lot of FUD. The news articles are filled with lots of speculation about what could happen, but very few facts.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Thu, 15 Dec 2005 19:15:49 -0500 (EST) Sean Donelan [EMAIL PROTECTED] wrote: ATT, 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 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 capability for their ISP customers from one of their VoIP product offerings specifically because the customers didn't want it. My impression is that DiffServ is not used by those types of networks you mentioned, but I'd be interested to hear that I'm mistaken. backbone is better than Best-Effort. Ok, maybe they aren't the Internet. Internet2 gave up on premium QOS and deployed less-than Best Effort scavenger class. Ok, may they aren't the Internet either. Scavenger is not currently enabled on Abielene. In fact, no QoS mechanisms are. On the other hand, those same QOS tools are very useful to the network engineer for managing all sorts of network problems such as DOS attacks and disaster recovery as well as more efficiently using all the available network paths. In my experience that is easier said than done. However, you remind me of what I think is what most who say they want QoS are really after. DoS protection. By focusing on DoS mitigation instead of trying to provide service differentiation, things begin to make more sense and actually become much more practical and deployable. John
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Thu, 15 Dec 2005, John Kristoff wrote: On Thu, 15 Dec 2005 19:15:49 -0500 (EST) Sean Donelan [EMAIL PROTECTED] wrote: ATT, 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? capability for their ISP customers from one of their VoIP product offerings specifically because the customers didn't want it. My impression is that DiffServ is not used by those types of networks you mentioned, but I'd be interested to hear that I'm mistaken. diffserv is the devil... and I think the voip product(s) in question aren't meant to be used in places where bandwidth is the constraint :) when you back that rack-sized (not kidding) PVG15000 up to your multi-oc-12 connection area you aren't really worried about bandwidth constraints. You may, however, want to heed the documentation provided which says to never, ever, ever connect the equipment to the public network... or not. On the other hand, those same QOS tools are very useful to the network engineer for managing all sorts of network problems such as DOS attacks and disaster recovery as well as more efficiently using all the available network paths. WRED comes to mind for this... sure. stop the sawtooth, make it smooth baby! In my experience that is easier said than done. However, you remind me of what I think is what most who say they want QoS are really after. DoS protection. By focusing on DoS mitigation instead of trying to provide service differentiation, things begin to make more sense and actually become much more practical and deployable. how does qos help with a dos attack? I've struggled with this several times internally, unless you remark everyone (in which case you'll be remarking good and bad and not getting any benefit) I'm not sure it does help... I'd be happy to be shown the error of my ways/thoughts though. Oh, and don't say: Well we qos icmp down to stop the icmp flood damage, silly! of course you do, and your attacker says: Gee icmp isn't working, what about UDP? What about TCP? What about I make my bots make full tcp/80 connections? Oh.. doh! no qos helps that eh? :( I could be wrong though.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005 03:29:29 + (GMT) Christopher L. Morrow [EMAIL PROTECTED] wrote: In my experience that is easier said than done. However, you remind me of what I think is what most who say they want QoS are really after. DoS protection. By focusing on DoS mitigation instead of trying to provide service differentiation, things begin to make more sense and actually become much more practical and deployable. how does qos help with a dos attack? My point is that it's not QoS, it's DoS mitigation. Whatever that means to you, that is the solution I think most people may ultimately be looking for when they say they want QoS. John
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 +, Christopher L. Morrow wrote: On Thu, 15 Dec 2005, John Kristoff wrote: On Thu, 15 Dec 2005 19:15:49 -0500 (EST) Sean Donelan [EMAIL PROTECTED] wrote: ATT, 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 pgpwYFugkpI8h.pgp Description: PGP signature
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Thu, 15 Dec 2005, John Kristoff wrote: On Fri, 16 Dec 2005 03:29:29 + (GMT) Christopher L. Morrow [EMAIL PROTECTED] wrote: In my experience that is easier said than done. However, you remind me of what I think is what most who say they want QoS are really after. DoS protection. By focusing on DoS mitigation instead of trying to provide service differentiation, things begin to make more sense and actually become much more practical and deployable. how does qos help with a dos attack? My point is that it's not QoS, it's DoS mitigation. Whatever that means to you, that is the solution I think most people may ultimately be looking for when they say they want QoS. ah-ha! and here I thought they wanted buzzword compliance :) From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
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 +, Christopher L. Morrow wrote: On Thu, 15 Dec 2005, John Kristoff wrote: On Thu, 15 Dec 2005 19:15:49 -0500 (EST) Sean Donelan [EMAIL PROTECTED] wrote: ATT, 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
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
ah-ha! and here I thought they wanted buzzword compliance :) From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else. and i wonder who is selling that need? randy
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
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 +, 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 http://www.1-4-5.net/~dmm/sprintlink_and_mpls.ppt 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
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005, Randy Bush wrote: ah-ha! and here I thought they wanted buzzword compliance :) From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else. and i wonder who is selling that need? the wierd thing is you'd think the telco would just say: Well gosh, sorry we can't help you squeeze 10lbs of poo into your 5lb bag, wanna by a shiney new 10lb bag? or maybe you meant equipment vendors? :)
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, Dec 16, 2005 at 03:52:20AM +, 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 +, 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 http://www.1-4-5.net/~dmm/sprintlink_and_mpls.ppt 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 pgpeiPMsDxxG6.pgp Description: PGP signature
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
ah-ha! and here I thought they wanted buzzword compliance :) From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else. and i wonder who is selling that need? the wierd thing is you'd think the telco would just say: Well gosh, sorry we can't help you squeeze 10lbs of poo into your 5lb bag, wanna by a shiney new 10lb bag? or maybe you meant equipment vendors? :) bingo! buy more, and more complex, hardware and you can charge more. what they forget to mention is that income will get blown in opex and capex (with the vendors getting the latter). randy
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005, Randy Bush wrote: ah-ha! and here I thought they wanted buzzword compliance :) From what sales/customers say it seems like they have a perception that 'qos will let me use MORE of my too-small pipe' (or not spend as fast on more pipe) more than anything else. and i wonder who is selling that need? the wierd thing is you'd think the telco would just say: Well gosh, sorry we can't help you squeeze 10lbs of poo into your 5lb bag, wanna by a shiney new 10lb bag? or maybe you meant equipment vendors? :) bingo! buy more, and more complex, hardware and you can charge more. what they forget to mention is that income will get blown in opex and capex (with the vendors getting the latter). charge more you say?? I need to talk to our marketting dept!!! :) The world of marketting and sales is so incestuously intertwined among consumers and consumee's ... it's an amazing thing.
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, 16 Dec 2005, Christopher L. Morrow wrote: http://www.secsup.org/files/dmm-queuing.pdf oh firstgrad spelling where ahve you gone? also at: http://www.secsup.org/files/dmm-queueing.pdf incase you type not paste.
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
Hey there Fergie: Martin, You can 'see' anything you'd like, buy your reality does not match everyone else's -- my opinion, of course. QoS is a myth -- it doesn't exist. What you're obviosuly trying to tell us is that less-than-best- effort is somehow good? Never sell it. This vein will come back and bite you guys who think like this. I'm not sggesting that this be the way the Internet operate at all. The poster asked how this would work if it did (my interpretation) and where there is will (customers) and money (ISP's) there is always a way. The old school in me says never!, but the experience in me says possible. I think it *is* unlikely though. Consider the busy signal approach for a second though. Can we build, pay for, and sustain an Internet that never has congestion or is never busy. If you have a web server and a limited amount of memory or net you tune down the number of httpd's that are spawned and when they are all busy, your site doesn't answer and you get a 404. That's akin to a busy signal and is already in practice today. If I'm Google, for example, I buy thousands of servers so this does not happen. If I'm just plain old me and I am running some popular faq on my personal site, I accept the 404's because I am not going to pay for 100% performance. They can try again later, or, I can pay for more memory or more network to insure optimal performance. Hope that makes a little more sense. And let me turn the question around to you. If the Internet were to work like this, how would we do it? - ferg -- Hannigan, Martin [EMAIL PROTECTED] wrote: What I'm interested in is how the two service providers will build a two tiered Internet. The PSTN is tiered both in architecture and operation. Switching hiearchies and a seperate SS7 network which is basically a billing network. I think the thought is service levels vs. congestion control. For example, CO's have call overflow mechanisms to tandem switch points which basically seek out excess capacity and use it as overflow for call termination if and when possible. I could see an internet hiearchy where preferred traffic was switch onto hicap overflow links with controlled congestion and other traffic, non premium traffic, got a fast busy. -M -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
RE: The Qos PipeDream [Was: RE: Two Tiered Internet]
Can we build, pay for, and sustain an Internet that never has congestion or is never busy. s/never/when there are not multiple serious cuts/ would we build a bank where only some of the customers can get their money back? we're selling delivery of packets at some bandwidth. we should deliver it. otherwise, it's called false advertising. randy
