Subject: [NSIS] RE: Update NSIS Charter (v 1.3)

From: [email-masked]
Date: Thu, 15 Nov 2001 11:51:28 +0200

Hi Bob,

[charter text clipped]

> It would be much better if you said what "existing methods" 
> you mean; that will help define the scope.  As one of the 
> principal designers of one "existing method", I wonder whether 
> you mean the Signaling Protocol Whose Name Cannot be Spoken in 
> PC Internet Circles...  Or ???

With regards to RSVP, at the end of the day, it is not a bad
protocol, it still has much applicability but could use
some clean-up.

> I wish I thought this was a technical judgment, not just an empty
> political statement.

I don't intend it to be an empty political statement.  May SDOs 
have looked at & considered using RSVP.  However, there
are known shortcomings with RSVP ...

[charter text clipped again]

> I believe you are skirting the edge of wishful thinking here. 
> In the QoS field, there has been an awful lot of wishful thinking 
> and throwiing around of fine-sounding phrases that in fact mean 
> nothing technically. It is simply nonsense to talk about "QOS-aware 
> services" if different parts of the path use incompatible service models.

Thanks for your comments.  I understand that proper scoping of 
the work is very important.

Additionally, I'd like to say that we are not looking for
a 'kitchen skink' approach here.  We are looking at using
RSVP to signaling QoS, seperated from any QoS reservation
schemes.  We should first look at what are the minimal 
requirements for QoS signaling, make a simplified
architecture (probably supporting some sort of QoS proxy 
in place of hop-by-hop), and examine some of the known
shortcomings in current solutions.

When we do that, I think that we will have a very good 
view on how to move forward.

> "What sort of QoS parameters to use" means the service model?
> 
> I have a great ideal for a simple QoS parameter set: one parameter
> called "niceness".  It has the advantage that every provider can do
> it.  You could have a scale of niceness = 0 to 63, for example.  Or,
> no, let's make it even simpler... lets have a binary niceness
> parameter, with values zero and one.  Ooops, I just reinvented the
> Controlled Load service model of int-serv.

There are quite often 2 camps when it comes to QoS.  One is
along the lines 'best effort was good enough for my grandfather,
so it is good enough for me.' The other camp tends to dig into
the parameters and looses sight of what might be important -
the user. 

From a user's perspective, I've usually encountered the following
attitude - 'I can't tell you what QoS is, but I know it when I
see/hear it.'  I believe this points to a possible simplification
on how we signaling QoS.

[more charter clipped]

> One year to develop requirements, architecture, and protocol?
> You can't be serious.

One can be hopeful ;)

> QoS is a hard problem.  That's why is has taken so long.  Many people
> are not willing to face up to that fact, which is why there is so
> much garbage written about it.

It is, I also believe that the entire field has become overly 
complex.  I hope with NSIS we can make a (over) simplification
in order to allow some level of QoS to be deployed on a wide
basis & support uses.  Wireless networks, in particular, could
take advantage of such a solution.  Of course, we may be pushing
the hard work for later (how to actually map signaling QoS
to resource reservations).

br,
John

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

---

From: Kathleen Nichols <[email-masked]>
Date: Fri, 16 Nov 2001 11:37:34 -0800

[email-masked] wrote:
...
[below from Bob Braden]
> the work is very important.
....
> see/hear it.'  I believe this points to a possible simplification

Although it's important to define what a user is going to get from
QoS, it's at least as important to figure out how a network can
deliver it. Too much user-emphasis can lead to coming up with
signalling semantics that let the user "ask for" something which
the network cannot deliver. To me, this goes along with the paragraph
above, from Bob Braden: that is, what the user has to signal for
something that a network provider can actually deliver and the
properties of that "quality of service" must be quantifiable since
the internal mechanisms of how the quality level is accomplished
are unlikely to be exposed. I'd like to see some emphasis on just
*what* is being signalled for, and some existence proof that it
is realizable.

	Kathie

---

From: Hermann De Meer <[email-masked]>
Date: Fri, 16 Nov 2001 20:28:29 +0000

Kathie,

>*what* is being signalled for, and some existence proof that it

I agree but like to put it the other way round:
  what *has* been *realized* that we are signalling?

In other words, while, for example, IntServ (and the like) is based on a 
well-defined
mathematical framework, DiffServ is not, something is missing here for usage
in an environment of interest: fixed net, wireless link etc.

To use these service you need to have the semantics well defined,
including the missing link. This would entail all elements of
a (possibly heterogeneous) QoS architecture:
Specification, Signalling, Admission, Scheduling

--Hermann

---

From: Ping Pan <[email-masked]>
Date: Mon, 19 Nov 2001 14:58:11 -0800

Kathie,

Kathleen Nichols wrote:

> deliver it. 

Agree. In addition, the scope of "network" is also important. Signaling 
for QoS for backbone networks, access networks (at regional level) and 
enterprise networks can be very different in nature. For example, the 
backbone providers need to focus on inter-provider negotiation, routing 
policy interface... where as the access networks need to make sure the 
signaling is simple and fast. In enterprise networks, hmmm... I am not 
sure there is a need for QoS signaling here.

> Too much user-emphasis can lead to coming up with

Yep. There are two types of "users":

   - smart ones: They are armed with adaptive capability and can adjust 
to network conditions dynamically.

   - dumb ones: for example, when providers blast thousands of voice 
streams into the Internet using a switch, that switch needs to signal 
for each stream to the Internet, but cannot apply any cool technique 
such as compression re-transmission at data level. The Internet must be 
able to handle such traffic.

So I would like to see a simple signaling mechanism to address both types.

> 	Kathie

- Ping