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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 9 Jul 2002 08:50:45 +0100

Hi Marco,

Maybe my one line clarification was a bit glib. What I really wanted to say was that there may be many 'reasons' for doing this signalling, and to emphasise that QoS is just one of them.

Whether NSIS is about resources or services or applications or quality thereof is a rather separate issue. I agree that we've not found it easy to specify the meanings of any of these terms or indeed think of better ones. So, any lightweight suggestions on this front would be helpful.

Robert H.

> -----Original Message-----
> From: Schneider, Marco [mailto:[email-masked]]
> Sent: 08 July 2002 21:40
> To: Hancock, Robert; [email-masked]';
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] New framework draft: Resource Management Function
> v.s. QoS Management Function
> 
> 
> 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
> > > > > 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 9 Jul 2002 23:58:25 +0100

Hi Dan,

Without wishing to appear negative about your proposal, I can't help pointing out a sentence in the 'clarified' charter (you can find it referred to in the interim meeting report): "It is out of scope of this working group to define what quality of service is." See also further down in this mail.

In any case, we're supposed to be working on signalling for more generic things than just QoS. What would be really incredibly useful (for a framework obsessive like me) would be a definition of the attributes of these "things" which actually affect what the signalling has to be able to do. But this seems to be a hard problem.

Cheers,

Robert H.

[Please note: I'm not saying that defining QoS is not an interesting general question. But given how hard it seems to be, maybe we should try to work out how much of a definition is actually needed to make progress in NSIS.]

> From: Dan Grossman [mailto:[email-masked]]
> Sent: 09 July 2002 20:35
> To: Schneider, Marco
> Cc: Hancock, Robert; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [NSIS] New framework draft: Resource Management Function
> v.s.QoS Management Function
> 
> 
> 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.
> 
> "Schneider, Marco" wrote:
> 
> > Hi Robert, all
> >
> > (quality of service) service being the ability to specify 
> the quality of
> > said packet transport service. For me, strictly speaking, 
> QOS is not an
> > > > Sent: 2002å¹´6æoe^27æ-¥ 17:47
> > > > To: 'Hancock, Robert'
> > > > Cc: [email-masked]
> > > > > Regards, RÃ¼diger

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 10 Jul 2002 15:45:29 +0200

Hi 

the draft draft-hancock-nsis-fw-00.txt provides definitions 
for several additional terms. These terms are described in "Section 2: Terminology"
of this draft.
I propose to introduce them into the requirements draft draft-ietf-nsis-req-0x.txt!

Can we get an agreement on this?

Best Regards,
Georgios

-----Original Message-----
From: Dan Grossman [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 9:35 PM
To: Schneider, Marco
Cc: 'Hancock, Robert'; [email-masked];

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.

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.

"Schneider, Marco" wrote:

> 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
> resources/capabilities and whether or not the service implementation uses
> > > I agree with the explanation given by Robert regarding RMF. I am in
> > > > > _______________________________________________
> > > > > 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

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