Subject: Updating LINK

From: Phil Karn <[email-masked]>
Date: Wed, 22 Nov 2000 15:14:27 -0800

Hi all. I've been going over the PILC mail since the last IETF and am
currently revising the LINK document before Friday's deadline. The old
obsolete text is now gone from my copy; the question is how to replace it.

In re-reading the discussion started by Dan Grossman's suggested new
text for the QoS section, a few things occurred to me.

I have always been struck by how discussions about QoS inevitably
become extremely abstract, and I believe this has kept QoS from making
much concrete progress in the real world.

For example, Dan's section begins with a fairly lengthy (and abstract)
review of current differentiated services work and ends with a single
paragraph that dealt directly with link design issues.  Given that not
much of a consensus was reached in the ensuing list discussion, I'm
inclined to leave out much of the review stuff in favor of pointers to
existing documents, and to keep his last section.

Since this is a document intended for subnetwork designers, any
recommendations we make about QoS should be in concrete terms that
subnetwork designers already understand. I still believe we should
simply point out that many subnetworks have "knobs" that can make
qualitative tradeoffs between competing measures of performance, that
applications differ in which performance measures they consider
important, give a few representative examples of such knobs, and
recommend that the designers not preclude the ability of some future
IP QoS mechanism to control them should the QoS folks ever figure out
what they really want to do.

Any comments?

Phil

---

From: Dan Grossman <[email-masked]>
Date: Mon, 27 Nov 2000 11:22:23 -0500

Phil,
The reason for the lengthy exposition was that most people who aren't actively 
involved in QoS work usually don't understand the issues.  My view was (and 
still is) that a "level set" is needed.  Unfortunately, there is not one RFC 
(and I haven't found a good single paper in the literature) that one can point 
to that has information of this nature.  

QoS stuff is somewhat abstract, because unless one starts at first principle, 
one is likely to get it wrong.  I disagree that "this has kept it from making 
progress in the real world."  There are other reasons, which rate a 
side-discussion in San Diego but are off topic for this list.

I don't think that the amount of exposiontion in my proposed text is 
inconsistent with the amount of exposition on, say TCP.  There probably is 
some material which could be cut back, and if you strongly need to do that, it 
could be done.  However, I really think your current version threw out the 
baby with the bathwater.  It also retained some material that is at least 
misleading if not incorrect, namely the first couple of paragraphs.

WRT subnet designers, in addition to the tutorial material, I think we need at 
a minimum to make the following points:
 -- QoS is quantitative and measureable.  QoS != priority.
 -- Don't waste your time on QoS classes;  use network mechanisms like RSVP to 
negotiate
  -- Don't assume that just setting a few bits in the IP header (TOS or 
Diffserv) solve your QoS problems
 -- QoS guarantees require cooperating mechanisms that play together as a 
system.  Some of these are not stateless.

I'm not able to do much on this for the next few days.  We can talk about this 
in San Diego, or if you can be specific as to how much material you think 
needs to be cut out, I can try to rework.

Dan