Subject: [NSIS] proposal to add requirement text

From: [email-masked]
Date: Thu, 21 Mar 2002 23:52:21 +0100

All,
 
off line discussions revealed that the scalability sections (5.6) could be slightly updated. 
 
I suggest wording along these lines: 
 
The nsis architecture should give the ability to constrain the load (CPU load, memory space, signaling bandwidth consumption and signaling intensity) on devices where it is needed. This can be achieved by many different methods, for example message aggregation, by ignoring signaling message, header compression or minimizing functionality. The architecture may choose any of these methods as long as the requirement is met. 
 
(the reasoning behind the words are the following, if I have the ability to control the load the protocol(s) generate in a singel device, the protocol will "scale". And the words does not mandate any particular solution)
 
A related requirement that was discussed was transport quality for the signaling protocol where I propose the following text. 
 
The nsis architecture should allow the network operator to assign the nsis protocol messages a certain transport quality. As signaling opens up for possible denial-of-service attacks, this requirement gives the network operator a mean, but also the obligation, to trade-off between signaling latency and the impact (from the signaling messages) on devices within his/her network. From protocol design this requirement states that the protocol messages should be detectable, at least where the control and assignment of the messages priority is done.   
 
Anders

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 22 Mar 2002 01:17:32 +0200 (EET)

Hi,

	the first req sounds good, but the second, IMO, is written the 
wrong way:

	"The signalling messages must be identifiable in an efficient  
way (with some definition of "efficient":)."

	This then allows a network operator to assign priorities etc. to 
those signalling packets. So, don't mandate what to do with the packets, 
but make it (easily) possible to handle these packets in a specific way.

	Cheers,

	JiM

On Thu, 21 Mar 2002 [email-masked] wrote:

>  The nsis architecture should give the ability to constrain the load
> (CPU load, memory space, signaling bandwidth consumption and signaling
> intensity) on devices where it is needed. This can be achieved by many
> different methods, for example message aggregation, by ignoring
> signaling message, header compression or minimizing functionality. The
> architecture may choose any of these methods as long as the requirement
> is met.

>  (the reasoning behind the words are the following, if I have the
> ability to control the load the protocol(s) generate in a singel device,
> the protocol will "scale". And the words does not mandate any particular
> solution)

>  A related requirement that was discussed was transport quality for the
> signaling protocol where I propose the following text.

>  The nsis architecture should allow the network operator to assign the
> nsis protocol messages a certain transport quality. As signaling opens
> up for possible denial-of-service attacks, this requirement gives the
> network operator a mean, but also the obligation, to trade-off between
> signaling latency and the impact (from the signaling messages) on
> devices within his/her network. From protocol design this requirement
> states that the protocol messages should be detectable, at least where
> the control and assignment of the messages priority is done.
>  
> Anders
>

---

From: Roland Bless <[email-masked]>
Date: Fri, 22 Mar 2002 01:15:38 +0100

Hi Anders,

I don't think that it really replaces the scalability statement, but
maybe a good addition to it. Scalability is usually about considering the
effects on system performance when scaling some system parameters in 
the order of magnitudes (different scales). This is somehow different
from the statement of minimizing/constraining things.

The second suggested paragraph on transport quality for the signaling
protocol is IMO a non-requirement (i.e. not really a requirement):
1. every protocol has some identifier in the lower layer (thus they are
   always "detectable")
2. although it is sensible and really desirable to have a faster/better/isolated 
   transport for signaling messages, it should be left to the provider
   to do so and if so by what means.

[BTW: please, can you break the lines into a reasonable length, 
because quoting is awkward otherwise?]

Regards,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked]
Institute of Telematics, University of Karlsruhe, Germany  
Zirkel 2, D-76128 Karlsruhe -- Office: Bld. 20.20, 3rd floor, R 358
Phone: +49 721 608-6413 Fax: +49 721 388097