Subject: [Ieprep] Re: Is QoS Dead?

From: [email-masked]
Date: Mon, 18 Nov 2002 09:47:27 EST

In a message dated 11/17/2002 10:32:31 AM Eastern Standard Time, 
[email-masked] writes:

> 
> All of which are irrelevant, because this is IETF, not ITU.
> 

> And those are equally irrelevant, because this is IETF, not ETSI.
> 
> If folks here would use clear language, the list would be more successful
> in communicating with each other.  "QoS" refers to a mechanism.  "Service
> Quality" refers to whether the provided service is good, bad, or sideways.
> 
> 

[MAP] Thanks for reconfirming to me and the group that you have no intention 
of trying to cooperate with other "recognized" standards bodies. (I already 
knew that you do not "recognize" them.)

You didn't comment on my quote from an IETF RFC that also appears to use the 
term "Quality of Service" the same way as ITU-T does. I'm certain I can find 
lots of other IETF documents that are also consistent with the ITU-T 
definition of the term. So there may be a terminology conflict within the 
IETF itself. Do we need to try to fix or change this?

Mike Pierce
Artel

---

From: "King, Kimberly S." <[email-masked]>
Date: Tue, 19 Nov 2002 13:12:11 -0500

On Tuesday, Nov 19, 2002, at 12:20 America/Montreal, Fred Baker wrote:
> My problem is that my traffic doesn't live only in the core - it goes 
> end to end,
> through the cores of several networks, and through at least one access

> network that
> gives me fits. Telling me that the core has no problem doesn't 
> convince me that
> my traffic will experience no problems. I can measure, and have given 
> you pointers
> to graphic versions of those measurements, that this is simply untrue.

Ran said:
>It would be pleasant (and seems to be the case) if we can simply agree 
>here that the primary problem lives in the access links, and hence the 
>access links should be the focus of efforts to improve service quality.

It seems a reasonable place to start is at the end systems and on access
links.  I do not feel there is any dispute that congestion is potentially a
problem within the Internet but I also know the probably of ieprep solving
that problem end-to-end.  So, let's focus on the most typical bottlenecks
where we have a good chance of success.

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Nov 2002 10:13:33 -0800

I have no idea how the ieprep list address got transmuted as it did. Ran's 
reply to me an hour or so ago was in response to this message.

>To: Bill Woodcock <[email-masked]>
>From: Fred Baker <[email-masked]>
>Subject: Re: [Ieprep] Re: Is QoS Dead?
>Cc: [email-masked], [email-masked], <[email-masked]>, 
>Internet Emergency Preparedness Working Group <[email-masked]>
>Bcc:
>X-Eudora-Signature: <<No Default>>
>
>At 09:01 AM 11/15/2002 -0800, Bill Woodcock wrote:
>>So, to clarify again:  In the Internet, we improved the quality of 
>>service by abolishing QoS.
>
>Bill, maybe you should call my IP Phone Number (+1-408-526-4257) tomorrow 
>when I am at home, and have me randomly turn on and off the QoS settings 
>during the call while sending competing traffic. Cox Cable limits my input 
>to their network to 128 KBPS (I have a choice of two SLAs: 128/128, or 
>792/128; either has the same effect on what I input), and absent specific 
>work-arounds of their cable modem configuration it can be pretty bad. 
>Geoff Huston, author of the theory that "just increase the bandwidth" 
>fixes all problems, makes nasty remarks about my quality of service when I 
>do that. You can look at some ad hoc measurements in 
>ftp://ftpeng.cisco.com/fred/common/
>NCHC_2002.pdf, slides 4-8.
>
>
>It's true that in the core of the top 100-or-so ISP networks and many 
>Fortune 500 enterprises, 10:1 overprovisioning coupled with strict input 
>limiting in the access paths has reduced the issues in the core. I haven't 
>seen measurements that suggest that the end to end (eg, PC to PC) behavior 
>is as much improved; it simply doesn't have issues in the core. The thing 
>is (a) not all networks own their own fiber or consider 10:1 
>overprovisioning to be the solution of choice, and (b) not all end users 
>or enterprises have the option of 10:1 overprovisioning at any price.
>
>You might be interested to look up Athina Markopoulou's recent 
>measurements of the backbone on that score, however; I think she has a 
>pointer to her recent report on VoIP performance in the Internet Backbone 
>in http://www.stanford.edu/~amarko/projects.html. Bottom line, as ingress 
>to the backbone is limited in the access networks (creating quality issues 
>in the access), the backbone is perfectly stable. Open the access networks 
>up to higher bandwidth, and she measures fractal behavior in the backbone. 
>Surprise.
>
>At 04:36 AM 11/16/2002 -0800, Bill Woodcock wrote:
>>The question is whether it has ever worked in the real world, and the 
>>answer to that is no, it always falls apart under the weight of its own 
>>complexity when it hits the real world.
>
>At 06:53 PM 11/15/2002 -0500, Scott  Bradner wrote:
>>So for folks who missed the RSVP experiment, I should note that a major 
>>problem with RSVP was that it created too much state in routers along the 
>>path and depended too much on that state being present (even though the 
>>path changes dynamically with time).  This NSIS stuff is likely to hit 
>>the same wall at least as hard.
>
>Actually, I *was* there for that experiment, and consider both of these to 
>be something of an overstatement. RFC 2206 worried about that as an issue. 
>A person (whose name I have, but in this forum will remain nameless) at 
>BBN tested it, and couldn't be convinced that trying to run 1.544 MBPS of 
>reserved IP traffic over a 1.544 MBPS link that also had to carry the HDLC 
>framing around that traffic, T-1 framing, routing, and btw RSVP might be a 
>bad idea. An equally nameless-in-this-forum person (unless she chooses to 
>identify herself) at MCI tested it for the vBNS backbone, made thoughtful 
>remarks, and requested (and got) specific developments done for mating 
>RSVP sessions to individual ATM SVCs across her network. Neither could 
>justify asking their company to roll out a service based on it, as there 
>was little or no demand for toll quality VoIP or Video/IP in the backbone 
>in 1995-1996. Neither mentioned complexity or scaling factors as feeding 
>into her decision.
>
>Maybe you could point me to published or unpublished research that 
>establishes that the RFC 2206 concerns materialized in reality?
>
>
>Mike and I have our differences of opinion, but on this point he and I are 
>in the same camp. The level of sarcasm and misinformation being expressed 
>on this topic is inappropriate given the published data on the subject. 
>You can measure (RIPE measures) that jitter within and between ISPs is 
>very nominal. That doesn't make it so end to end, and the infinite 
>bandwidth option doesn't exist end to end. Until it does, we're going to 
>have to deal with applications with specific QoS requirements in places 
>that are not blessed with infinite bandwidth.

---

From: "Nguyen, An" <[email-masked]>
Date: Wed, 20 Nov 2002 10:01:17 -0500

I have been on travel and had quite a lot of email messages to go through. 
Anyway, is it fair to say that QoS problems exist between the endpoints and
edge nodes of the Internet(provided that the Internet backbone is perfectly
stable)? We all acknowledge them, but don't know how or want to solve them
because ,as some ops folks mentioned early on, RSVP and Diff-Serv are not
scalable.

Question: Do we have any standard that provides a QoS traffic mapping
mechanism between endpoints (i.e., 802.1q/q) and edge nodes (i.e., diff-serv
and mpls)? In order to have end-to-end QoS, we need to have such a
mechanism.

An

---

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

At 10:01 AM 11/20/2002 -0500, Nguyen, An wrote:
>Do we have any standard that provides a QoS traffic mapping

802.1q is a link layer technology, and therefore does not scale to the 
internet. If you think diffserv is unscalable, replacing it with a set of 
link layer priorities on only one of the many types of interfaces that are 
used in the internet is not going to be an improvement.

---

From: "Nguyen, An" <[email-masked]>
Date: Wed, 20 Nov 2002 11:56:13 -0500

Fred,

I am not in a position to say that Diff-Serv is unscalable. I just repeated
some scalability concerns with Diff-Serv raised by someone early on. 

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.

Regards,

An 

-----Original Message-----
From: Fred Baker
To: Nguyen, An
Cc: [email-masked]
Sent: 11/20/02 11:25 AM
Subject: RE: Re: [Ieprep] Re: Is QoS Dead?

802.1q is a link layer technology, and therefore does not scale to the 
internet. If you think diffserv is unscalable, replacing it with a set
of 
link layer priorities on only one of the many types of interfaces that
are 
used in the internet is not going to be an improvement. 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: "Nguyen, An" <[email-masked]>
Date: Fri, 22 Nov 2002 04:03:12 -0500

I found the below article from Network World today and I think it is
interesting and relavant to what has been discussed in this WG.

---------------------------------------------
Today's focus: Taming UDP 

 By Steve Taylor and Joanie Wexler 

 The User Datagram Protocol is used for transporting traffic 
 types that depend more on speedy packet delivery than on 
 reliable delivery.  As noted in our last newsletter, UDP 
 differs greatly from the other IP transport protocol, TCP, in 
 this respect. 

 One notable application that depends on UDP, of course, is 
 voice over IP. 

 UDP, while it does not generate the network overhead associated 
 with the highly reliable, connection-oriented TCP transport, 
 lacks any form of congestion control. This means that it does 
 not receive any feedback about real-time network conditions and 
 will just continue sending packets merrily along regardless of 
 whether they are moving at a snail's pace or are falling on the 
 floor. 

 In this way, UDP, ironically, can actually make a network 
 congestion problem worse and impact the performance of all 
 protocols on the network. At some point, VoIP delays could 
 degrade a conversation beyond salvation. 

 So what are you to do to "tame" UDP's behavior under these 
 circumstances? There are some traffic management products, 
 which we've covered in this newsletter before, that manage 
 problem children such as UDP. 

 For example, Packeteer says it has built in some controls for 
 outbound UDP traffic into its PacketShaper bandwidth-management 
 device. Upon an Internet client request from a server, 
 PacketShaper steps in to regulate the pace of the UDP packet 
 flow at the sending side. This rate regulation takes place 
 before packets traverse a WAN access link, where congestion is 
 most likely to occur. 

 The controls function in way that seem analogous to a jitter 
 buffers, which "smooth out" the delivery of VoIP packets - 
 albeit at the receiving end - for a more predictable, and 
 better-quality, conversation. 

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Sent: 11/21/02 10:49 AM
Subject: Re: [Ieprep] Re: Is QoS Dead?

In a message dated 11/21/2002 7:11:13 AM Eastern Standard Time,
[email-masked] writes: 

Fred said: 
>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? 

It is also important to ask the right questions.  Is world peace
important? 
Yes, I believe it is but what chance do we have solving it (were it
within 
the charter) in ieprep? 

[MAP] Since previous e-mail exchanges on this list indicated out that
there is a difference of opinion on what "QoS" means, as used in the
above several sentences (both valid meanings), could I suggest that
there are separate questions as follows: 

1. "Is there a need to worry about the quality of an end-to-end
service?" 
2. "Is there a need to figure out ways to improve the quality of an
end-to-end service?" 
3. "Is there a need to provide an end-to-end protocol to support the
improvement in the end-to-end quality of a service?" 
4. "Is there a need to guarantee perfect end-to-end quality?" 

These are very different questions. I believe the answers are: 

1. Absolutely yes. 
2. Yes, at least in some cases. 
3. Maybe. 
4. No, trying to do this would be like getting total world peace. 

Mike Pierce 
Artel