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

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 15 May 2002 10:00:33 +0200

Hi John

> I think so.  RSVP, with IntServ removed is probably
> applicable.  That is why it has been suggested we look at
> 
> "Specification of the Null Service Type - RFC 2997"
> 
> "A Framework For IntServ Operation Over Diffserv Networks - RFC 2998" 

I guess this latter one is the true charter of NSIS. 

This RFC 2998 mentions "admission control" only
39 times, "resource" pops up 77 times, 
"reservation/dynamic/policing/shaping/provisioning/mapping"
together contribute another 75 hits. Only fools could 
believe that RFC 2998 is related to entities involved
in the reservation of resources.
 
> > > 1) entities involved in the reservation of resources are 
> > >    out of scope.

> My personal (non-chair) opinion, would be that if we could
> do the above in a reasonable time period, we would have
> some interesting tools to do interesting things. 

Yes.

Regards, Rüdiger 

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 15 May 2002 12:22:01 +0200

Hi John,

right now we may have a private conversation, the NSIS 
mail server may be broken. To contents..

> As far as BB go, I don't think we need to completely
> ignore them, however, I don't think we can make NSIS
> a BB-centric archiecture.  What I mean is that we cannot
> mandate a BB architecure (i.e. - everyone who wants to
> use an NSIS protocol MUST deploy a bandwidth broker.)
> I see it more as something that the signaling can occur
> without a BB, but we may be able to put the correct
> hooks to allow those who want to deploy BBs to be able to
> do so. 

The problem then is the "one protocol only paradigm". 
Speaking as a representative of my company, the aim is 
to deploy switched IP QoS services. The signaling 
architecture is certainly less important than the 
time to market.
Consequently, I never expected a BB to be the one and
only solution. I'm favouring a twofold approach, 
centralized versus decentralized modes. Of course
both must be compatible. In the end, a carrier could
choose what best suits his needs. 
I'll try to live with this, maybe NSIS is able to solve
that knot. 

> To put it another way, I don't think that the IESG will
> let us standardize Bandwidth Brokers, nor is that something
> that I want to do.  However, it is possible that NSIS
> could support BBs, if they are present.

To repeat that: I never expected NSIS (or any other forum)
to standardize a BB. Service related signaling between 
separate BB's, that's all I hoped could be supported. Not 
quite fulfilled, but NSIS may not be too far away too. Thinks are 
clearer to me now. 

Thanks for the discussion.

Regards, Rüdiger

---

From: [email-masked]
Date: Wed, 15 May 2002 13:26:19 +0300

Hi,

> mail server may be broken. To contents..

Its just slow.
 
> I'll try to live with this, maybe NSIS is able to solve

What I think is that one protocol might not solve everything
that we want.  If we discover that we need more than
one, then we should flag this need.  We may need to recharter
the working group at this point, or simply focus on one
part of the problem to begin with.  I am nearly 100% positive,
that if we are successful, we will be creating the need
for more work in the future - however, let's start with
what we can.
 
> quite fulfilled, but NSIS may not be too far away too. Thinks are 

I hope they are clearer & hopefully statisfactory as well.

John

---

From: [email-masked]
Date: Wed, 15 May 2002 11:38:22 +0300

Hi Rüdiger,

RFC 2998 discusses "Integrated Services Over Diffserv Networks."
Some folks (meaning area directors & IESG folks) have thought
that a more general solution is needed, meaning that 2998 is
a specific implementation of the general solution.  So, 
for example, there could be other solutions like:

	IntServ over MPLS Networks
	IntServ over Over Provisioned Networks
	Intserv over a Bandwidth Broker Network
	... 
	etc.

Furthermore, maybe someone does not want IntServ exactly,
but perhaps a certain characteristic of IntServ, say 
bandwidth.  Then you could have

	Bandwidth Assurance over IntServ Networks
	Bandwidth Assurance over MPLS Networks
	Bandwidth Assurance over Over Provisioned Networks
	Bandwidth Assurance over a Bandwidth Broker Network
	... 
	etc.

Finally, what do you do when one party of a call/session has
one 'kind' of network and the other party has a different 
'kind'?  You could do a hop-by-hop approach, at each
hop modifying or translating the necessary parameters,
but this gets ugly fast and may not work.  Perhaps it is
better to have a general solution, then work later on
how the general solution can be mapped down to a specific
network or resource reservation mechanism.

> in the reservation of resources.

I don't get your point.  Can you restate it?

John

---

From: [email-masked]
Date: Wed, 15 May 2002 12:57:33 +0300

Hi Rudiger,

> > bandwidth.
> What happens to the remainder of IntServ in that case? 
> Would one have to signal empty parameters? No answer 
> required if this will be discussed in Helsinki!   

My feeling is we should discuss what parts we signaling,
but we de-couple the signaling from the resource reservation.
 
> >     Then you could have
> That BB definition issue must be settled. The "friends 
> of BB" could provide an architecture outline by now, 
> if they are not charged of entering the solution discussion. 
> It would be helpful to have such a document (and I see
> by your other message that you aggree). Your above 
> example in my words would be:
> 
> BW Assurancee over MPLS using a BB
> BW Assurance over Over Provisoned Networks using a BB
> or in general: BW Assurance over a network using a BB
> 
> BB's of separated domains may 
> signal with each other without bothering which 
> layers/technologies are supported by the domain
> in which each operates. This solves the problem 
> you've mentioned below (with regard to signaling):  

John

---

From: [email-masked]
Date: Fri, 17 May 2002 11:54:20 +0200

Ruediger, John, all,

Would it be fair to say then that we can indicate in the signaling that:
a. we want to reserve resources
b. how many we want of what type
but
c. without actually participating in the implementation or saying how it
must be done.

We can discuss next week if needed,
Sven.

[email-masked] on 15/05/2002 11:57:33

  To:          [email-masked]                    
                                                              
  cc:          [email-masked](bcc: Sven VAN DEN                
               BOSCH/BE/ALCATEL)                              

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

Hi Rudiger,

John

---

From: [email-masked]
Date: Fri, 17 May 2002 15:46:44 +0300

Hi,

> b. how many we want of what type but
> c. without actually participating in the implementation or 
> saying how it must be done.

I think that a. could be re-worded to state:

a. We want a service, which could be a resource reservation 
   or require resource reservation.

John

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 17 May 2002 14:03:19 -0400

Since whatever is requesting service cannot know how exactly resources are
measured or managed I think that (b) should be expressed in terms of QoS
requirements/parameters of the data flow the service is requested for.

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 17, 2002 8:47 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [NSIS] RE: What's in the charter of NSIS

Hi,

John

---

From: [email-masked]
Date: Sun, 19 May 2002 19:56:13 +0300

Hi Gary,
 
I have yet to understand your point.  If you feel the current
document is missing something, please speak up.
 
Right now, I am under the assumption that the WG will
not define the format of the QoS object to be signaled.
 
John

-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 17 May, 2002 20:14
To: 'Bob Braden'; Loughney John (NRC/Helsinki); [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] RE: What's in the charter of NSIS

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 

> 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 
>   *> 
>

---

From: [email-masked]
Date: Sun, 19 May 2002 20:07:15 +0300

Hi Gary,

> I think the distinction that can be made is that NSIS should be able to 
> describe the QoS requirements, including resource constraining QoS 
> specifications such as the Tspec. And, there should be an interaction 
> with NSIS and admission control. However, there are other resources that 
> may need to be provisioned for QoS such as filters, queues, etc., and we 
> would really have to show a significant advantage in managing these 
> resources with NSIS rather then one of the existing solutions. 

These can all be considered services, and are out of scope
for NSIS.  NSIS will not define these.

John

---

From: [email-masked]
Date: Mon, 20 May 2002 14:44:04 +0300

Hi Xiaoming,
> > One can think of the term 'QoS' in the charter as
> > a use case for the signaling protocol developed in NSIS.
> 
> Do you indicate the "use case" is also going to be developed in NSIS?
> Maybe then we need some format of e.g., QoS object? Thanks.

This work would be possible after we fulfill our charter, and
recharter the working group.

John

---

From: "Gary Kenward"<[email-masked]>
Date: Tue, 21 May 2002 12:13:03 -0400

John:

  And, if you look back into the archives, you will notice that I have made
the
same point a number of times - that NSIS should not be defining QoS or QoS 
objects. However, we did get into a rat hole on resource allocation, and in
the 
discussion, the role of NSIS in conveying bandwidth requirements (as part of

the QoS object), and perhaps interacting with important control points such
as 
admission control, seemed to become unclear. 

  I was simply trying to clarify this when I was criticized for following
the thread,
and I must say, adhering to the charter. I note that the charter does not
say that 
"QoS is a use case scenario for a general signalling protocol". 

  It may be useful to say that NSIS is the first step in a series of
evolutionary generations
of a general protocol. But the intent should be clear, not "implied".
References to QoS signalling 
appear in almost every paragraph, and I cannot find any references to other
types of signalling that
NSIS itself is supposed to support. So, are Bob and Lixia correct in their
criticism of my posting?
Should we start talking about the general requirements for signalling? Or,
should we continue as 
we have been, trying to solidify the requirements for QoS signalling, which
seems to be contentious
enough.

  I think it is  dangerous to pretend that NSIS will be a general protocol,
when the only application 
driving the requirements and the framework is QoS. And, I do not know how we
can discuss these specific
requirements, without being focussed on QoS.

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: May 19, 2002 12:56
To: Kenward, Gary [WDLN2:AN10:EXCH]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] RE: What's in the charter of NSIS

Hi Gary,

 
John
-----Original Message-----
From: ext Gary Kenward [mailto:[email-masked]]
Sent: 17 May, 2002 20:14
To: 'Bob Braden'; Loughney John (NRC/Helsinki); [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] RE: What's in the charter of NSIS

> From: Bob Braden [mailto:[email-masked]] 
> Sent: May 17, 2002 12:47

---

From: "Schneider, Marco" <[email-masked]>
Date: Fri, 31 May 2002 12:11:03 -0500

> could support BBs, if they are present.

John,

What is your current view on this in light of recent discussions and charter
scoping announcements?

Marco

> Sent: Wednesday, May 15, 2002 4:58 AM
> Subject: [NSIS] RE: What's in the charter of NSIS
> 
> 
> Hi Rudiger,
>