Subject: RE: [NSIS] New framework draft: Resource Management Function v.s. QoS Management Function

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 8 Jul 2002 15:40:27 -0500

Hi Robert, all

I find our mapping of distinctions to terms confusing. The term QOS is of
course short for Quality of Service. This begs the question "what or which
service". In our context we seem to be speaking of packet transport: A QOS
(quality of service) service being the ability to specify the quality of
said packet transport service. For me, strictly speaking, QOS is not an
example of a resource but rather a type of service that can reasonably be
thought of to require resource reservations in a network. What resources are
actually reserved or utilized to achieve QOS is beyond the scope of our
work. Put another way a service is an abstraction of network
resources/capabilities and whether or not the service implementation uses
said abstractions is beyond scope.

Marco

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]]
> Sent: Thursday, June 27, 2002 5:45 AM
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] New framework draft: Resource Management Function
> v.s. QoS Management Function
> 
> 
> Hi Zhigang,
> 
> 'QoS' is one example of 'resource'.
> 
> I'm actually not sure it is possible to define 'resource' 
> precisely. The basic point is that NSIS should provide a 
> generally useful signalling capability, which you could use 
> for various types of resource; exactly what types is going to 
> be defined implicitly by whether the NSIS capabilities are 
> appropriate to the resource type needs. In that sense, 
> there's a benefit in vagueness.
> 
> An RMF is absolutely not a BB. In our framework, "RMF" is 
> just a name for what NSIS offloads certain problems in 
> resource management to, it's a way to talk about the boundary 
> of the NSIS problem space. NSIS doesn't care how the RMF is 
> implemented; it should be possible to support both 
> centralised and distributed resource management strategies 
> with the same NSIS protocol. The one thing that is ruled out 
> (initially) is NSIS signalling directly to a centralised 
> (off-path) entity; this is a consequence of recent scope 
> guidance. Please see especially section 5.1 of the draft (the 
> hardest section to write, by the way). 
> 
> Yours,
> 
> Robert H.
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 27 June 2002 11:11
> > To: [email-masked]; Hancock, Robert
> > Cc: [email-masked]
> > Subject: RE: [NSIS] New framework draft: Resource 
> Management Function
> > v.s. QoS Management Function
> > 
> > 
> > Hi all,
> > 
> > Maybe we don't care what term/name is called. The most 
> > important is that the "resources" and "resource management" 
> > should be defined exactly, and the relationship between 
> > resource and QoS should be clarified. Is RMF similar as BB?
> > 
> > BR/Kan Zhigang
> > 
> > -----Original Message-----
> > From: ext Georgios Karagiannis (ELN)
> > [mailto:[email-masked]]
> > Sent: 2002年6月27日 17:47
> > To: 'Hancock, Robert'
> > Cc: [email-masked]
> > Subject: RE: [NSIS] New framework draft: Resource Management 
> > Function v.
> > s. QoS Management Function
> > 
> > 
> > Hi all
> > 
> > I agree with the explanation given by Robert regarding RMF. I am in
> > favor of keeping the term RMF.
> > 
> > Best Regards,
> > Georgios
> > 
> > -----Original Message-----
> > From: Hancock, Robert [mailto:[email-masked]]
> > Sent: Thursday, June 27, 2002 11:39 AM
> > To: 'Geib, Ruediger'; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [NSIS] New framework draft: Resource 
> Management Function
> > v.s. QoS Management Function
> > 
> > 
> > hi all,
> > 
> > I think it's valuable for Zhigang to highlight the point, 
> > because this is one of the major changes in this NSIS 
> > framework input compared to (most?) previous ones (certainly 
> > the ones I have been involved in). One of the consequences of 
> > the email discussions around the time of the interim meeting 
> > (e.g. 
> > http://www1.ietf.org/mail-archive/working-groups/nsis/current/
> > msg01378.html) was that we should look at more general 
> > resources than just QOS. (IMHO, this is still not obvious 
> > even in the post-interim clarified charter, BTW.)
> > 
> > This has quite a big impact on what we write, at least. We 
> > still need a good name for this "thing we are signalling 
> > for", "resource" (and hence RMF) is a first guess. 'Service' 
> > seems to me to be too general. The key point which is special 
> > about NSIS is that the relevant resources are those which 
> > have to be provided by entities along the data path, but I 
> > can't think of a snappy term for that.
> > 
> > The other impact is that we might need to broaden our 
> > thinking about how such a signalling protocol might fit into 
> > an overall solution to some resource management problem 
> > (hence my interest in Marcus' firewall draft). Certainly, the 
> > relationship between nsis and midcom/tist activities seems 
> > important to understand.
> > 
> > Robert H.
> > 
> > > -----Original Message-----
> > > From: Geib, Ruediger [mailto:[email-masked]]
> > > Sent: 27 June 2002 10:10
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [NSIS] New framework draft: Resource 
> > Management Function
> > > v.s. QoS Management Function
> > > 
> > > 
> > > Hi Kan,
> > > 
> > > > Resource Management Function is introduced in this draft as 
> > > > "RMF: an abstract concept,  representing the management of 
> > > > resources in a domain or a node". I think that this 
> > > > definition is not appropriate for the aim of NSIS which is 
> > > > Signaling QoS, not Signaling resource. 
> > > 
> > > And if it is going to be perfectly in the sense of IETF, NSIS 
> > > is not only about QoS signaling, it is about service related 
> > > signaling in general. What about calling the above system 
> > > "Service Management Function"?
> > > 
> > > Regards, Rüdiger
> > > 
> > >  
> > > > Hi all,
> > > > 
> > > > A group of us who were involved in past NSIS framework 
> > > > activities got together after the interim meeting to put 
> > > > together a joint framework document in the form of an all-new 
> > > > individual submission. It (roughly) follows the structure 
> > > > that was introduced and refined at that meeting.
> > > > 
> > > > ==============================================================
> > > > ============
> > > > Abstract 
> > > >  
> > > >    The NSIS working group is considering protocol 
> developments in 
> > > >    signaling for resources for a traffic flow along its 
> > path in the 
> > > >    network. The requirements for such signaling are being 
> > > > developed in a 
> > > >    separate document; This Internet Draft proposes a 
> > framework for 
> > > >    such signaling. This initial version provides a model for 
> > > > describing 
> > > >    the entities that take part in the signaling and the 
> > > ways in which 
> > > >    they can be used in different modes of operation. It also 
> > > > discusses 
> > > >    the overall structure of such a signaling protocol. 
> > Finally, it 
> > > >    considers the possible interactions of NSIS signaling 
> > with other 
> > > >    protocols and functions, including security issues. 
> > > > ==============================================================
> > > > ============
> > > > 
> > > > While it works its way through the i-d editor queue, you can 
> > > > find a copy here:
> > > > http://www.epic.roke.co.uk/epic/draft-hancock-nsis-fw-00.txt
> > > > 
> > > > Comments are welcome. There is a list of open issue 
> > > > highlights in section 3.
> > > > 
> > > > Cheers,
> > > > 
> > > > Robert Hancock
> > > > 
> > > > _______________________________________________
> > > > nsis mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > 
> > > 
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > > 
> > 
> > _______________________________________________
> > 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: Dan Grossman <[email-masked]>
Date: Tue, 09 Jul 2002 15:35:07 -0400

Perhaps what is missing is a definition of Quality of Service.  This has been a
long standing problem in the RFC series:  I'm not aware of a single place where
the term is defined.  It is also true that the industry has no single accepted
definition.  While I'm not convinced that this is the right place to put such
definitions, there doesn't seem to be a better one right now.

The following may be a good start toward working definitons:

Quality-of-Service(QoS):  A set of attributes and their values that, taken
together, characterize the performance experienced by a flow.

End-to-end QoS:  A set of attributes and their values that, taken together,
characterize the performance experienced by an end-to-end flow, i.e., as
observed by protocols above the IP layer

Edge-to-edge QoS:  A set of attributes and their values, that, taken together,
characterize the performance experienced by a flow from the point where it
enters a domain (or a concatenation of domains) to the point(s) where it leaves
that (those) domain(s).

Agreed QoS:  A set of attributes and their values that have been agreed between
a network (or concatentation of networks) and two (or more) hosts.  This set
characterizes the performance the network(s) agree that a flow will experience
for a defined period.  The agreement can be reached through signalling  or
administratively.

Actual QoS:  The measured values of a set of QoS attributes.