Subject: RE: [NSIS] RE: What's in the charter of NSIS

From: "Gary Kenward"<[email-masked]>
Date: Fri, 17 May 2002 13:14:21 -0400

It is a valid observation that my point was very much into the
detail. However, it had nothing to do with how Int Serv, Diff
Serv or any other QoS model happens to work. It had everything
to do with the on-going thread as to whether NSIS was chartered
to look at resource allocation (which is not). I was simply attempting
to draw a distinction between QoS specification and resource allocation.
In no way did I intend d to imply, nor do I believe that I actually implied,
that NSIS was building the next QoS "model".

As for the point that Lixia was making, I think it is a valid one,
However, correct me if I am wrong here, but the charter states:

"This working group will develop the requirements, architecture and 
protocols for the next IETF steps on signalling QoS. The working group 
will use existing IETF signalling as the basis for this work, evaluating 
RSVP in particular as the starting point. Additionally, the working 
group will consider how to signal QoS (what sort of QoS parameters to 
use), and where to signal (end-to-end, end-to-edge, end-to-proxy, 
edge-to-edge, etc.)."

Sounds like NSIS is really NSIQoSS, if one was to worry about names
(a rose is a rose . . .).

Finally, I do agree that NSIS should absolutely be defined with some 
attention to future needs, as long as we keep it real. Predicting
the future is neither easy, nor reliable.

Cheers,
Gary

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: May 17, 2002 12:47
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [NSIS] RE: What's in the charter of NSIS
> 
> 
> 
> Lixia wrote:
> 
> ...
> 
>   *> 
>   *> But I cannot help throwing a comment on this specific 
> one: NSIS stands for
>   *> "Next Step in Signaling", not next step in QOS.
>   *> 
>   *> I personally do NOT think a signaling protocol should 
> involve itself into
>   *> the definitions of what QOS requirements should be.
>   *> QOS requirements may change over time, yet one wishes 
> that the signaling
>   *> protocol, which is used to carry the QOS requirements, 
> does NOT have to
>   *> change.
>   *> 
>   *> Besides, there WILL be other uses of a signaling 
> protocol other than QOS
>   *> need.  My understanding is that NSIS is chartered to 
> look into the need for
>   *> a signaling protocol, NOT the QOS requirement.
>   *> 
> 
> I want to say "amen" to all of that.
> 
> The original message from Gary Kenward included, "... QoS
> specifications such as the Tspec." The Tspec is not by itself a QoS
> specification.  In fact, even talking about "a QoS 
> specification" is to
> oversimplify a complex process, which may involve two passes, one pass
> with advertising, etc.  There are many possible QoS models; int-serv
> chose just two of them.  And NSIS should choose NONE of them; a
> next-generation signaling protocol should be able to handle any future
> model.
> 
> This observation, together with Lixia's comment, leads me to the
> realization that RSVP may have had the modularity wrong (and 
> NSIS might
> pay attention to this point).  RSVP design and specification may ahve
> talked too much about int-serv specific things like Tspecs.  We should
> instead have defined RSVP strictly in terms of transporting opaque QoS
> objects upstream and downstream, and applying some model-specific
> algorithms at merge and branch points.  The definition of 
> these objects
> and algorithms would then be completely contained in documents that
> define QoS models.
> 
> Our vision was imperfect when we began the Internet 
> integrated services
> work in 1993.  If we had gotten the modularity better, we 
> would perhaps
> have avoided some of the immense amount of misunderstanding that is
> still current about Internet QoS issues.
> 
> BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a
> better modularity.
> 
> Bob Braden
> 
> 
> 
> 
>   *> My personal 2 cents,
>   *> Lixia
>   *> 
>   *> 
>   *> _______________________________________________
>   *> nsis mailing list
>   *> [email-masked]
>   *> https://www1.ietf.org/mailman/listinfo/nsis
>   *> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 17 May 2002 10:48:35 -0700

On 5/17/02 10:14 AM, "Gary Kenward" <[email-masked]> wrote:

> protocols for the next IETF steps on signalling QoS.

I personally believe that statement is an inaccurate description of NSIS's
goal, it's inconsistent with prior discussions that led to the birth of this
WG (of course there is also a possibility that I understood incorrectly).

I brought up this issue with the area ADs earlier.

I fully agree that this issue needs to be clarified.

> The working group