Subject: RE: Updating LINK

From: [email-masked]
Date: Fri, 24 Nov 2000 07:04:24 -0600

snip/snip

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?

Well yes I agree with the approach. I think we have erred maybe a bit to
much on the high level advice :-) I think for QoS in particular whatever is
at the edge of the subnet has to do the "translation" from what the
application/session needs into what the subnet can deliver (or cannot
deliver for that matter). In any subnet that does encapsulation or
segmenting of the IP packet there are often a native set of QoS "levels"
that will be used and mapped to the diffserv classes. Phil, are you
suggesting we (pilc) should define the mapping mechanisms or the QoS
signaling (some RSVP-light for edge devices that are not routers?) and look
at subnet-level admission control based on resource management methods? I
think that would be valuable but maybe worth of a draft of it's own. 

Marie-Jose

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 27 Nov 2000 17:44:35 -0500

Dan:

  I could not agree with your email more. It echoes every point I have been
trying to
designers for the last year. 

  While I also agree with your statement "QoS is quantitative and
measurable", I have
found that the Diff Serv model tends to, at best, muddy the water. Subnet
designers
tend to want to define Classes of Service and specify performance bounds
(c.f. 3GPP
QoS). I consider this a bad approach, as it embeds, at the subnetwork level,
QoS
definitions that are ultimately application driven.

  If I understand your observations completely, you are proposing a
"parametric control"
approach to QoS configuration on the subnet (perhaps using RSVP)? Do you
foresee any 
problems in saying as much in the draft?

Regards,
Gary Kenward

==========================================================================
Gary W. Kenward
[email-masked]
Advisor, Wireless Architecture               (613) 765-1437
Advanced Technology Labs                      FAX: (613) 763-2686

Nortel Networks
==========================================================================

As far as the laws of mathematics refer to reality, they are not certain;
and as far as they are certain, they do not refer to reality.
-- Albert Einstein

-----Original Message-----
From: Dan Grossman [mailto:[email-masked]]
Sent: Monday, November 27, 2000 11:22 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Updating LINK

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