Subject: RE: [NSIS] New NSIS-related drafts

From: [email-masked]
Date: Wed, 18 Sep 2002 08:52:04 +0300

Hi Melinda,

> One thing that pops out in a quick first scan of the
> document isn't an issue that's peculiar to CASP but is
> something that I think NSIS needs to consider, and that's
> failure modes.

Without a doubt, however, I would like to ensure that
the failure mode handling is done in as straight forward 
manner as possible, and be more focused on informing the
end-systems (so that end-systems can make the decisions
on what to do) and maintaining packet flow.

> If an interesting node along the path fails to process an
> NSIS or CASP (or, indeed, RSVP) message, the results can
> be unfortunate but not catastrophic, or catastrophic (in the
> sense that it causes the path to fail).  An "interesting
> node" is one that should process and respond to the request
> (i.e. a router for a QoS request, a firewall for a firewall
> request, etc.) but that doesn't support the request
> protocol.  That is to say, it won't honor the request but it
> won't send back a message to the originator saying that it
> won't honor the request.  If it's a QoS request it's
> probably not going to be catastrophic, unless the network is
> tightly engineered and running near capacity.  

The protocol mechanism for this would require some level of
reliability at the NSIS-layer.  So, if some middle box blocks
the NSIS protocol, but does not report an error, then the
end-systems at either end will need to time out, retry or
do something.  

I think we can split this into two pieces:

	Failure detection 
	Failure recovery

Failure detection would probably be optional, but could do things
like rely on lower-layer mechanisms (e.g. - SCTP heartbeats) or
could have some sort of network probing mechanism (something
that is suggested by the CASP scout mechanism, or even PATH
mechanism of RSVP.

Failure recovery would be somewhat more complicated and probably
requires some sort of ability for NSIS-aware nodes to keep 
a cache of NSIS neighbors so that alternative routes can 
be tried.
 
> What would be ideal in a protocol to be used to communicate
> with firewalls is protocol machinery that fails if a given
> firewall along the path that is not {NSIS,RSVP,CASP}-capable
> drops the {NSIS,RSVP,CASP} request rather than passing it
> along.  It's not something that can be designed in and
> guaranteed, but the probabilities can be jimmied.

I agree with you on this.  We discussed some issues around this
at the interim meeting.  Perhaps some discussion on 
draft-vandenbosch-nsis-resilience-00.txt could be useful and
perhaps the WG could add input into the draft so that 
the issues you outlined would be covered.

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 30 Sep 2002 16:50:50 +0200

Henning,

I like tha CASP document and I think it is a useful draft. The "capability" parameter is not mentioned in the "message Format" section. I'd expect it to be present there. It is an integral part of every CASP message, isn't it?

One such capability could be "QoS". The second draft describes a QoS client. The casp-qos draft is not as elaborated as the CASP draft. It repeats one of the major drawbacks of IntServ/RSVP: it doesn't separate a service identifier from a service descriptor. Different services will require different descriptors. Some examples:

- Internet2's Scavenger Service requires signalling 
  of a DSCP only. It is just turned on or off (it 
  is "Less Than Best Effort").
- A globally well defined service only requires a 
  limited set of parameters (ideally, bandwidth 
  will do it) and a DSCP.
- IntServ may require a couple of other parameters.
  A DSCP may be required.

I'd suggest the following:
A Service Identier MUST be present in every CASP-QoS reservation message. Depending on the service identified, a service descriptor containing service specific parameters is present. If the service itself doesn't require further description than just a service ID, we are fine.

Assuming the CASP-QoS protocol to establish signalling for DiffServ domains, PHB-ID and DSCP MUST be present and could form parameters outside of the service dewscriptor (they could be part of the Service ID).

The maximum/minimum bandwidth procedure seems to be the only feasible way of realising a simple negotiation mechanism. I still feel it to be too complex and would favor a single bandwidth as only requirement for the protocol. I'd be curious in learning more about application developers views on that.
If negotiation is kept, how are things handled for bidirectional reservations? A reservation will still be accepted if one direction gets maximum resources while the other gets minimum? 

I'd also favour the basic CASP-QoS protocol to be free of any pre-emption mechanism. Not every QoS service does require support of emergency calls (e.g. Internet2's Scavenger Service doesn't). Pre-emption adds signaling load and operational complexity and should at best be optional.

Further, there's a parameter "L2 properties". It should be removed without replacement. Layer 2 issues are opaque to NSIS signalling. A network operator learns which service is required by NSIS signaling. The operator then decides whether his network meets these service requirements or whether it doesn't. If NSIS signaling will contain a Layer 2 specific service descriptor combining every possible layer 2 with every possible interpretation of service mapping per operator, we don't need NSIS. by the way, didn't we agree to limit NSIS strictly to layer 3?

Regards, Rüdiger

Rüdiger Geib
T-Systems
Systems Integration
Senior Expert, Technologiezentrum
Am Kavalleriesand 3, 64295 Darmstadt
Germany
Fon: +49 6151 832138
http://www.t-systems.com