Subject: Re: [NSIS] proposal to add requirement text

From: Marcus Brunner <[email-masked]>
Date: Thu, 04 Apr 2002 13:01:03 +0200

On the scalability issue, I tend to agree with Roland here as well. So my 
proposal is to add Anders text but keep the scalability text (can be 
removed later if required) objections.

I agree with Roland on the second thing (the priority on signalling 
messages) If the protocol is not detectable we have a problem anyway. And 
Anders even says it in the last sentence of the paragraph "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."

And I read the paragraph such that it is the providers business what he 
wants to do, but from the architecture and protocol point of the 
requirements states that it needs to be poswsible that the provider can do 
it.

And I agree with Anders that the difference lies more in what for the 
requierements document is used.

If Jukka has no major concerns I will include the Anders text for the next 
version of the doc. Title of Requirement I propose "Ability to assign 
transport quality to signaling messages"

Marcus

--On Friday, March 22, 2002 1:15 AM +0100 Roland Bless <[email-masked]> 
wrote:

> 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
>
>> 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
>
> --
> 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
>
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

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

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Tue, 9 Apr 2002 12:59:14 +0200

Hi Anders

Sorry for the delay on sending this reply.
Regarding your proposal on scalability.
Actually I agree, but I would very much appreciate if you could 
change the following sentence:
" to constrain the load (CPU load, memory space, signaling bandwidth 
consumption and signaling intensity) on devices .."

into:

" to constrain the load (CPU load, memory space, signaling bandwidth 
consumption and signaling intensity) and the number of reservation states
on devices .."

Best Regards,
Georgios

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: donderdag 21 maart 2002 23:52
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] proposal to add requirement text

All,
 
off line discussions revealed that the scalability sections (5.6) could be slightly updated. 

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