Subject: what is an NSIS requirement? [was: RE: [NSIS] Comment on draft-ie tf-nsis-req-00.txt]

From: "Hancock, Robert" <[email-masked]>
Date: Sun, 17 Mar 2002 16:29:58 -0000

John & Sarantis,

I agree with your reasoning, but maybe it exposes my confusion about something more fundamental. (It's similar to the subject of Ilya's latest email, which I have not yet fully analysed.)

When we say "x.y.z is a requirement for NSIS" or "NSIS shall/must/may" or whatever, it seems we could be saying any of a large number of different things, like
a) there is a single ubiquitous NSIS protocol, and we are writing requirements for the core functionality that must be implemented in every node using it [one extreme], or
b) there are several components to a QoS signalling framework (e.g. in the same way that there are several components to the Internet routing framework), and some features may be useful, possibly optional parts of one component [the other extreme - essentially, the NSIS requirements are a formalised statement of NSIS scope]

I'm 100% behind the view that 5.3.7 must not be a requirement under view (a), but <<100% under view (b). In particular, I don't like assuming a single protocol; in any case, if NSIS 'happens' one can be sure that people will try to hack these 'nice to have' features into it in some localised way in the future (look what has happened with RSVP after all).

If we could sort this out before more agonising over any particular requirements, I think progress would be faster. Easier said than done, though...

Robert H.

PS. To draw an extremely tortuous analogy with the 'toolbox' phrases in the charter: not everyone has to have the same set of tools in their own toolbox. and not everyone has to use all the tools in their toolbox. but if a capability is useful, it's useful to have a standard tool for it. is NSIS a set of possible tools or a standardised toolbox?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 15 March 2002 22:59
> To: [email-masked]; Hancock, Robert
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [NSIS] Comment on draft-ietf-nsis-req-00.txt
> 
> 
> Robert,
> 
> I still don't really see this  a requirement.  It could
> be a nice feature, in some environments, but I'm
> not completely convinced that it is really useful.
> Additionally, it will create state in the network 
> and I'm not sure that is so good, especially in the
> case when there are not enough resources.
> 
> John
> 
> > > in this particular case, i think the requirement came from 
> > the context of not wanting to have a frustrated QI polling an 
> > access network (e.g. a cellular one) at some ridiculous rate 
> > to find out if resources have become available. (note in 
> > particular that it is quite hard in some cellular 
> > architectures to bill for this sort of polling, so far as i know.)
> > > 
> > > in some environments, this will be worth doing, and in some 
> > it won't. i guess that makes it a SHOULD (which is what the 
> > draft says), and there are a number of different modularity 
> > approaches which would minimise the pain caused by providing 
> > it as an option. (existence argument: QI says 'I want QoS for 
> > flow labelled by reference R', QC responds in the event of 
> > failure with either 'sorry, try later, in the meantime i've 
> > forgotten about R' or 'sorry, i'll tell you later, in the 
> > meantime don't ask again for flow R'. related tricks are 
> > needed in mobile scenarios. if QI doesn't want notification 
> > it omits R. the overhead in the protocol is some optional 
> > fields, which either end can ignore. i'm not saying that this 
> > is the right way to do it, but i don't see that allowing this 
> > as a should causes too much pain for people who don't 
> > actually want to implement the functionality.)
> > 
> > In that case the requirement should probably be:
> > 
> > "The QI MAY (or SHOULD) support being automatically notified 
> > from QCs for resources not previously available"
>