Subject: RE: [NSIS] Operational QoS signaling protocol requirements

From: [email-masked]
Date: Fri, 3 May 2002 11:28:23 +0300

Hi Rüdiger,

Some comments - I am not sure what an NSIS signaling unit is.
Have we defined it somewhere?  Is it hardware or software,
is a software process, a thread or what?  I don't think it
is useful to include this term in any requirements.

> 5.12.1 Backwards compatibility
> A later version of an NSIS protocol must be backwards 
> compatible with earlier versions of an NSIS protocol.

I don't support this.  What earlier version of NSIS
protocols are you talking about?
 
> 5.12.2 Unexpected situations and error restistance
> An NSIS protocol must define behaviour of NSIS signaling 
> units during unexpected situations. Unexpected situtions are 
> unknown messages, parameters and parameter settings as well 
> as receiption of unexpected messages (e.g. a "Reservation 
> Confirmation" without prior "Reservation Request").

I think John Postel's words of wisdom are sufficient:
'Be generous in what you recieve and conservative in what
you send.'
 
> 5.12.3 Default behaviour
> An NSIS protocol must define default behaviours and parameter 
> settings wherever applicable. 

Disagree with this, I don't think we can mandate this at all.
 
> 5.12.4 Extendability
> An NSIS protocol must provide means to enhance a protocol 
> with future procedures, messages, parameters and parameter settings.

I don't support the we 'MUST provide means to enhance ..' that is
too strong.  Extensibility is not a bad thing, but managing this can be
very difficult

> 5.12.5 Preventation of stale state
> An NSIS signalling protocol must provide means for an NSIS 
> signaling unit to discover and remove local stale state. This 
> may for example be done by means like soft state and periodic 
> flooding or by a polling mechanism and hard state signaling.

I am not sure about this either, there are a few things embedded
in this requirement, and I think this is already covered in other 
requirements.
 
> 5.12.6 Reliable Communication
> NSIS signaling procedures, connectivity between units 
> involved in NSIS signaling as well as the basic transport 
> protocol used by NSIS must provide a maximum of communication 
> reliability. Procedures must define how an NSIS signaling 
> systems behaves if some kind of request it sent stays without 
> answer (this could require e.g. be timers, number of message 
> retransmits and release messages). 
> An NSIS signaling unit must be able to check its connectivity 
> to an adjacent NSIS signaling unit at any time (this 
> requirement must however not result in a DoS attack tool - 
> the frequency of these checks must be limited, and flow 
> control may be useful). 
> The basic transport protocol to be used between adjacent NSIS 
> units must ensure message integrity and reliable transport.

What is 'maximum reliability' - who should provide this
function - is it an NSIS protocol, is it the transport protocol
NSIS runs on top of, is it provided by the network? I don't
like this requirement.

> 5.12.7 Smooth breakdown
> A unit participating in NSIS signaling must no cause further 
> damage to other systems involved in NSIS signaling when it 
> has to go out of service.

I don't think this is a useful requirement.

John

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

---

From: Marcus Brunner <[email-masked]>
Date: Fri, 03 May 2002 12:34:30 +0200

> 'Be generous in what you recieve and conservative in what

I pretty much like the requirement, because it is about taking care in the 
design and standardization of a potential protocol. Specifically the error 
resistance, even if implementation specific in many regards, is very 
important for operating a network using NSIS.

> Disagree with this, I don't think we can mandate this at all.

This one I like as well. Standardized default behaviour enhances the 
reliability.

> in this requirement, and I think this is already covered in other

Here I think we have covered it in other reqs, but potentially not enough. 
As said in a previous mail, soft state is a solution for various issues, so 
explicitly having a req on stale state (garbage collection in OO systems) I 
find useful.

> I don't think this is a useful requirement.

Here I agree with John. I have problems to see how we could meet this req 
in  a protocol or architecture.

Marcus

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