Subject: RE: Re: [Ieprep] Re: Is QoS Dead?

From: Fred Baker <[email-masked]>
Date: Wed, 20 Nov 2002 11:39:45 -0800

At 11:56 AM 11/20/2002 -0500, Nguyen, An wrote:
>So back to the QoS issue, Fred, is there a need to provide end-to-end QoS?
>what are the existing machanisms (e.g., RSVP, Diff-Serv, NSIS)? Can we use
>them to provide QoS? Is there a need to work on a new machanism? Or can we
>say that IP was designed to tranport data and that is the end of the QoS
>story.

"provide end to end qos" is an interesting description.

I'm told that I sometimes speak in code; let me pass along the code that I 
am using when I describe something as "interesting". I have taken school 
groups out to the Catalina Island Marine Institute to learn something about 
marine science. They are invariably given the opportunity to disect a 
squid, and (being sixth graders) are told that there is one thing that they 
are not allowed to say during the process: "yechh! gross!". They are 
instructed, instead, to say "in-ter-est-ing"...

As Ran and others pointed out yesterday, "provide end to end qos" can mean 
a number of things:
  - "make sure that packets get through with certain delay/jitter/loss 
characteristics
    end to end"
  - "install specific queues for specific data streams with specific 
characteristics"
  - "place circuit-like calls for specific data streams"
  - "ensure that there is capacity in a call-like basis, and then handle as an
    aggregate in the data plane"
and so on

I think, if you listen carefully to Ran, Bill, and Dave, they would say 
that it is important in the Internet to ensure that packets get from here 
to there with predictable latency etc. Ran's fifth slide makes that point 
strongly: he wants to drop no packets *and* deliver predictable delays. 
 From that perspective, it is a business imperative that the top ISPs 
deliver predictable service to their customers, and they take delivery of 
predictability very seriously. End to end QoS, by that definition, is very 
important. (Guys, correct me if I am wrong on your viewpoints)

Some of those ISPs will also tell you that a customer's ability to run 
specific applications over their service is also important, and some will 
tell you that this is the customer's problem. Without naming names - it's 
not my place and there are confidentiality issues - I can tell you that my 
company has worked with some ISPs specifically to ensure that voice will 
work well in their backbones, and some of those represented in this 
discussion are among those who have taken Voice on IP seriously. If you 
look at Athina's paper, which I posted a pointer to yesterday, she points 
out that some US ISPs (the kind that are being represented as "without 
problems" and instructing those of us who are "without clue") experience 
interesting (see "code" above) problems with respect to specific 
applications requiring detailed quality, especially voice. They don't all 
exhibit the behavior in the same way: some do pretty well, and others 
measurably don't.

There is research in progress (early reports available in the literature, 
more detailed reports in progress) on the hypothesis that at during the 
9/11 stuff, there were snap losses of BGP connectivity between major ISPs 
that were not related to link loss, but to BGP session loss due to link 
swamping. I don't know about you, but I consider losing routing to be 
rather an impediment to delivering a reliable internet service.

Yesterday afternoon, soon after interacting in this exchange, I had a 
telephone call with an ISP (whom I cannot name for obvious reasons, but it 
is not a US ISP; it lives in a part of the world where it pretty much has 
to lease its fiber from a semi-government telco that runs a competing ISP, 
and is therefore quite expensive) that has gone through and deployed 
several classes of traffic and WRED on its links with the objective of (a) 
using them at > 70% capacity and simultaneously (b) providing predictable 
service to its customers. They would agree, I think, with Ran's comment on 
slide 3 that the viewpoint he stated "is a little US-centric". I have had 
customers walk up after I give talks and thank me for taking into account 
that not everyone owns their own fiber, not everyone is governed by US 
telecom law, and bandwidth, when you have to buy it from a competitor who 
also happens to be the local telecom+ISP monopoly, is not free or even 
cheap. The fact that these companies don't come to the IETF and announce 
that they are delivering service under interesting conditions (see "code" 
above, and Ran's slide 13) doesn't mean they don't exist. It means that 
they don't want to publicly hand their competitor a weapon and put on a 
"kick me" sign. Discounting their experience as irrelevant to the clueful 
doesn't help.

Do we need end to end explicit assurance of a certain quality, in the sense 
of per-call reservations, specified queues for fine-grained behavior 
aggregates, and so on? No, we don't, and even if we did, that approach has 
interesting (see "code" above) scaling properties.

There are some applications that have specific requirements, and if one 
wants to run those applications over the backbone, their requirements need 
to be met. In the core of the top 100 ISPs globally and Fortune 500 
companies, we have been able to meet most of those issues by supplying 
bandwidth. In at least some cases, this has meant gerrymandering the use of 
that bandwidth in specific ways to reduce the overall cost of running a 
network, which is where MPLS Traffic Engineering enters the picture. 
Frankly, if bandwidth was as cheap and available as the presentations on 
Monday made it sound, there would be no interest in that technology. But at 
the same time, the fact that traffic engineering technology materially 
addresses many of the issues argues equally effectively that finer grain 
considerations are not obviously warranted.

Many of the applications that run over the Internet are essentially 
elastic. On this point, I would strongly suggest that you stop reading this 
email, read http://www.ietf.org/rfc/rfc1633.txt, sections 3.1.1 and 3.1.2, 
which define the terms I am about to use, and then come back.

         <pause>

Having now read that, you are well aware that providing appropriate service 
for these applications is not about providing hard delay bounds or specific 
rates to individual sessions. It is about getting the messages through with 
high probability and humanly-acceptable levels of delay. For example, 
consider instant messaging. If you have ever sat in a chat room or its 
"blackberry" equivalent, you are well aware that message deliver is not 
snappy. The fact that it gets through at all is quite sufficient - and is 
what has been put forward as making internet chat a desirable and effective 
tool for emergency services support. Asking service providers to do 
interesting (see "code") things to make this service "wonderful" doesn't 
meet any specific objective in Harald's requirements document, as long as 
the service works at all.

Not all applications are elastic. For those that, in RFC 1633's terms, 
require "real time" service, and which I call "inelastic" by comparison to 
"elastic" applications, there are other issues. Specifically, I am 
referring to voice and video; there are probably other applications with 
these characteristics, but they don't come quickly to mind. The first issue 
is the assurance of the availability of bandwidth when the bandwidth is 
needed, which implies a policy comparing amount of bandwidth needed, amount 
of bandwidth available, and the authorization of the potential user of the 
bandwidth. If bandwidth is infinite when compared to the potential load, 
this falls out: in my home, I have one IP phone, and enough bandwidth to 
handle it, so I personally don't need extensive authorization machinery. If 
I have a large number of IP phones and the sum of the bandwidth they could 
imaginably use exceeds the available capacity, that is another issue. 
Generally, it is a valid assumption that only a certain proportion of users 
can be expected to use the phone at any given time. If it is reasonable to 
expect that under extraordinary conditions they might literally all attempt 
to place a call, then those policy considerations are real. note that I 
haven't told you how to solve the problem - there are many ways, including 
spending infinite budget to procure infinite bandwidth, SIP polcy, RSVP 
policy, and so on; my point is that someone has to somehow ensure that the 
people who need the bandwidth and are authorized to use it have access to 
it, by whatever means is chosen. The second is that, given the availability 
of bandwidth, the BER and variation in delay is within bounds acceptable to 
the application. Anyone who has seen little squares on a TV screen or has 
had the equivalent of a bad telephone circuit in a VoIP conversation can 
tell you why this is important. Again, I'm not telling you how to solve it, 
but the fact is that the issue is measurably real and does indeed require a 
solution.

>So back to the QoS issue, Fred, is there a need to provide end-to-end QoS? 
>What are the mechanisms...?

We are involved, here, in what amounts to a discussion of technological 
religion, business issues, and user requirements.

The user requirements, I think you would agree, are that specific 
applications work when the chips are down to support emergency workers. If 
you are dealing with a specific link layer issue on a specific link, link 
layer facilities such as DOCSIS and 802.1q (now part of 802.1d, I believe) 
can be helpful. In the case of my VoIP services, which run over a VPN 
running over at least two service providers and two edge networks (Cisco's 
and my home), they can be helpful but don't address the issues end to end. 
Working around them involves identifying the application and ensuring that 
the voice traffic (which is encrypted and inside an IP datagram) gets the 
right service from the DOCSIS modem or the routers surrounding it. That 
winds up meaning handling the issues at an IP layer in the router in my 
office and a router at Cisco, because I am working around a service 
provider which is not Bill Woodcock, Ran Atkinson, or Dave Meyer, and 
(judging from its external behavior) appears to think that following their 
principles of service deployment conflict with its business plans or 
realities.

The possible technical alternatives are bandwidth, signaled QoS policy, and 
provisioned QoS configurations at the IP layer to work around the very 
different provisions in place at the link layer. The technical choice will 
be made by some combination of the religion and business viewpoints of the 
various folks involved. I'm 23,000 feet from the CO, so changing to a DSL 
provider (which would be cheaper and give me much more bandwidth) is not an 
option. So for me, the only available option is to use some form of QoS 
technology to work around the provider. Arguing that because the provider 
has not deployed it himself there is no requirement for the technology is, 
therefore, an interesting (see "code" above) argument to make...

Is there a need for end to end QoS? I dunno, I think there's only a need if 
you want your inelastic applications to reliably work end to end. Is that 
important? 

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 20 Nov 2002 18:38:28 -0500

On Wednesday, Nov 20, 2002, at 14:39 America/Montreal, Fred Baker wrote:
>  In at least some cases, this has meant gerrymandering the use of that 
> bandwidth
> in specific ways to reduce the overall cost of running a network, 
> which is
> where MPLS Traffic Engineering enters the picture. Frankly, if 
> bandwidth was
> as cheap and available as the presentations on Monday made it sound,
> there would be no interest in that technology.

Au contraire.  You totally discount the power of marketing and that 
power is
not trivial.  And at least two significant vendors of large routers 
have been
pushing MPLS in a huge way, often to customers who don't need or want 
it.

Please lets not confuse marketing with engineering or at least admit
that marketing often has a big impact on what gorp gets deployed
in at least some networks.

Ran Atkinson
[email-masked]

PS:	Unless memory failes me, the mpls-haters list is run by Sean Doran
	of sprint.net.  So I suspect he doesn't use any MPLS in his network.

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 21 Nov 2002 00:44:11 +0000

> in at least some networks.

there are two types of marketing -- one to build mass, and the other
to build on existing mass.  the initial one should be taken with a
skeptical eye

> 	of sprint.net.  So I suspect he doesn't use any MPLS in his network.

on the other side of the coin, my understanding was that uunet has been
running (and marketing :-) MPLS for a while (perhaps 1 to 2 years?) for
TE.  that of course is not an endorsement of MPLS, but just that someone
has decided its satisfactory for them

-ken

ps, as a side note, one ISP engineer working on MPLS told me that its
really just beneficial for a couple of dozen ISPs, period.  And that its
not an excuse for grossly poor capacity planning. ie, its not a panacea.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep