Subject: [NSIS] about the text related to scalability!

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 19 Apr 2002 15:48:57 +0200

Hi Marcus

Some time ago I have sent a comment on the 
text related to scalability.
It relates to the Open issue (11) that has been proposed 
by Anders Bergsten to replace the scalability requirements.

In that e-mail I proposed to replace the 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 .."

This is not shown in the current version of the NSIS WG draft.

In my opinion the number of reservation states impacts much more severely
the network performance compared to the 
impact of the load (on a node) on network performance!

Best Regards,
Georgios

-----Original Message-----
From: Georgios Karagiannis (ELN) 
Sent: dinsdag 9 april 2002 12:59
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] proposal to add requirement text

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. 
 
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

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