Subject: RE: [NSIS] What is the goal of the analysis draft?

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 4 Dec 2002 17:30:14 +0100

Hi Melinda 

In my opinion the scalability on the number of reservation states 
is an important issue that we should consider during the 
design process of the NSIS protocol.

To give a definition of the term scalability on 
the number of states,  see below: 

Scalability is a factor that shows how the performance of a node,
expressed in number of reservation states, is affected by increasing 
the number of network users (or application flows).

Maybe we could modify the scalability on the number of reservation states 
requirement as below:

"The NSIS signaling protocol should scale in terms of number of 
reservation states no worse, and when possible better, than linearly 
with the number of users (or application flows)."

Best Regards,
Georgios

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: woensdag 4 december 2002 16:42
To: Michael Thomas
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [NSIS] What is the goal of the analysis draft? 

>    Thus, I think it's fairly easy to derive a requirement
>    out of that:
> 
>    o The protocol must allow for explicit and intentional
>      topology changes which are not subject to route
>      flap damping procedures.
> 
>    I'm not sure I'd want to leave it up to the protocol
>    desiners to *realize* that's a requirement if it's
>    just in the middle of some analysis document. 

I absolutely agree with this.  I think that right now the
requirements document suffers a bit from the inclusion of
things that aren't really requirements (much of the
scalability section, for example), while it's one function
of a requirements document to bring out non-obvious
requirements like this one.  

Also, while I agree with the need to move as quickly as
possible, I don't think it's a good idea to try to move
*more* quickly than it's possible in order to head off
efforts by other standards bodies.  We need to produce the
best quality protocol we can within a reasonable time frame,
and I'd rather see us achieve that by constraining the
problem than by omitting important pieces of the process.

Melinda

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 04 Dec 2002 13:23:53 -0500

I think that it's pretty clear that "scalability" is not a
particularly meaningful term when it comes to laying out
requirements.  I would prefer to see things like "must
support message aggregation" than "should limit the load on
devices."   Maybe this needs to be thought of in terms of
what would happen if it were not included.  Do you think
that if section 5.5.5 were omitted, people designing a
protocol would then think "the heck with network
efficiency?"

Melinda