Subject: [Ieprep] Is QoS Dead?

From: [email-masked]
Date: Fri, 15 Nov 2002 14:38:22 EST

In a message dated 11/14/2002 7:30:18 PM Eastern Standard Time, 
[email-masked] writes:

> On Wednesday, Nov 13, 2002, at 16:33 America/Montreal, [email-masked] 
> wrote:
> > And there have been clear comments from others who do not believe that 
> > "QoS is well behind us".
> 
> Which person who is actively engineering or operating a commercial ISP
> has said anything like that on this list ?  I must not have received that 
> email.
> 
> There have been no comments from folks with no experience or involvement 
> with
> operating a commercial ISP (or the DoD production IP networks, for that 
> matter)
> suggesting that QoS is not well behind us.  And a number of us didn't go
> there even when it was the fad.
> 
> 

[MAP] Not on this list, since it isn't the scope of this WG (which is why I 
am somewhat embarrased to be posting this, but it seems to be at the heart of 
some of our issues.)

Am I understanding you to say that all attempts to improve the QoS of IP is 
dead? I'm confused, as I'm sure others are, then, why the following are on 
the agenda for the upcoming IETF:

NSIS (charter says "will develop requirements, architecture, protocols for 
... signaling QOS, ... evaluating RSVP as a starting point") is meeting for 
3.5 hours.
MPLS (isn't that one of the claimed ways to improve QoS) is meeting for 2.5 
hours

Are you saying that these WGs should be disbanded?

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 12:01:17 -0800 (PST)

On Fri, 15 Nov 2002 [email-masked] wrote:
    > dead?  I'm confused.

You're confused because you're having trouble with language again.
Specifically, you're making the same mistake that we've corrected twice
before: you're conflating the word "quality" with the acronym "QoS".  The
former is generally thought to mean a property of goodness, while the
latter is an abbreviation of "Quality of Service," which is a proper noun
denoting a collection of protocols and practices which have the intention
of making some pigs more equal than others.

So, to clarify again:  In the Internet, we improved the quality of
service by abolishing QoS.

See?  A tip: you can distinguish proper nouns because they're denoted by
the use of _initial capitals_.  Boeing, Big Mac with Cheese, QoS, Mike;
these are all proper nouns, tokens which designate a thing, rather than
being parts of the language which carry intrinsic meaning.

Before you get carried away, though, remember that decapitalizing
something isn't a useful trick, since it _changes the meaning of the thing
drastically_, as in the case before us now.  The confusion which this
engenders in proles is why, for instance, the word acme has been so
frequently used in the names (which are proper nouns) of businesses.

                                -Bill

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Nov 2002 21:06:47 -0500

On Friday, Nov 15, 2002, at 14:38 America/Montreal, [email-masked] 
wrote:
> Am I understanding you to say that all attempts to improve the QoS of 
> IP is dead? I'm confused, as I'm sure others are, then, why the 
> following are on the agenda for the upcoming IETF:
>
> NSIS (charter says "will develop requirements, architecture, protocols 
> for ... signaling

NSIS is working on an application-layer problem of telephony signalling 
applications,
not on IP-layer QoS.  ISPs generally only offer IP forwarding as a 
service, not
SIP or other application layer services.  I doubt anything done in NSIS 
will relate
to anything that actually gets deployed at the IP-layer.

>  QOS, ... evaluating RSVP as a starting point") is meeting for 3.5 
> hours.

RSVP was deployed in some limited ways.  It did not scale even to those 
very limited
deployments.  RSVP is pretty much abandoned as a QoS mechanism, based 
on that experience.

> MPLS (isn't that one of the claimed ways to improve QoS) is meeting 
> for 2.5 hours

At the moment, I think you can probably even find folks who claim that 
MPLS
is a "Ginzu Knife".  Most of the MPLS work these days seems to focus on 
its
use for:
	- Traffic Engineering
	- Virtual Private Networks, at layer-2 or layer-3
	- NOT for QoS, though it has an optional-to-implement DiffServ-like 
mechanism,
       that comes with all the issues that DiffServ has

> Are you saying that these WGs should be disbanded?

I'd suggest reading the recent IAB document on this topic:
	ftp://ftp.ietf.org/rfc/rfc2990.txt

I think Bill used a bit of hyperbole (but not a lot of hyperbole) in
calling QoS dead.  Folks wish they could find a way to make it 
deployable.
None such has been found yet and there are no obvious candidates in 
sight
just now.

Ran

---

From: Scott Bradner <[email-masked]>
Date: Fri, 15 Nov 2002 21:25:06 -0500 (EST)

> applications
> not on IP-layer QoS.

clarification - nsis is working on a protocol to install state in
devices along a path - this could be used for installing QoS or other
information in routers

Scott

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 18:16:05 -0800 (PST)

On Fri, 15 Nov 2002, RJ Atkinson wrote:
    > Folks wish they could find a way to make it deployable.

Hm.  Perhaps.  If so, they're vastly outnumbered by the folks who wish
they could find a way to make everyone permanently forget it existed.

                                -Bill

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Nov 2002 21:54:16 -0500

> devices along a path - this could be used for installing QoS or other

That is helpful.

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.

Ran

---

From: Scott Bradner <[email-masked]>
Date: Fri, 15 Nov 2002 21:53:44 -0500 (EST)

one hopes that there has been learning going on

----
>From [email-masked]  Fri Nov 15 21:52:55 2002
Date: Fri, 15 Nov 2002 21:54:16 -0500
Subject: Re: [Ieprep] Re: Is QoS Dead?
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: ieprep <[email-masked]>
To: Scott Bradner <[email-masked]>
From: RJ Atkinson <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.548)

That is helpful.

Ran

---

From: David Meyer <[email-masked]>
Date: Sat, 16 Nov 2002 04:14:21 -0800

>> the same wall at least as hard.

As Ran said, we've seen this film before (INT-SERV, ATM per flow
state, etv). It hasn't been sucessful yet. Is there
something that makes us think it will be successful now? 

Dave

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 16 Nov 2002 09:53:06 -0500

> to anything that actually gets deployed at the IP-layer.

John Loughney can speak for 'his' group, but I don't think this is 
correct. To cite the NSIS framework document 
http://www.ietf.org/internet-drafts/draft-ietf-nsis-fw-01.txt:

    NSIS will work on signaling from an end point that follows a path
    through the net that is determined by layer 3 routing and is used to
    convey information to the devices the signals pass through - the
    signaling can, for example, install soft state in the devices it
    passes through. A signaling end point could be a device along the
    path, which signals for a data flow that passes through it.
...
   The NSIS protocol is intended to be used as a signaling control plane
    for the variety of network resources required for data traffic across
    the Internet. The most common NSIS signaling applications are QoS
    resources, firewalls and NATs resources, etc. The NSIS signaling
    itself does not depend on the signaling application it is used for
    but the information it carries does. This section discusses the basic
    signaling entities of the protocol as well as interfaces between
    them.

> deployments.  RSVP is pretty much abandoned as a QoS mechanism, based on
> that experience.

In fairness, it should be noted that the initial scaling problems were 
partially related to a "demo" implementation becoming a production 
implementation, and falling flat on its face. (Rumor has it that 
signaling state was searched by linear search, which works fine for a 
demo, but doesn't for real load.)

There are clear existence proofs (see the work at TU Darmstadt) for RSVP 
implementations that scale to several hundred thousand call setups a 
second on commodity platforms. Thus, even if every single phone call in 
the US would traverse a single RSVP router, you'd be easily be able to 
keep up with the signaling load itself.

We have done similar measurements on RSVP - even on a lowly 68020 router 
of five years ago, you're very unlikely to run out of CPU resources for 
reasonable assumptions.

I suspect that "scaling" is much more of a problem in terms of AAA and 
interdomain trust issues rather than state or CPU resources.

Henning

---

From: Bill Woodcock <[email-masked]>
Date: Sat, 16 Nov 2002 07:36:12 -0800 (PST)

> of five years ago, you're very unlikely to run out of CPU resources for

The question is not whether people in labs think it's a neat idea, which
is quite clearly the case...  This kind of garbage always tickles lab
people pink.  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.

                                -Bill