Subject: [NSIS] General comments on draft-ietf-nsis-fw-01.txt

From: Bob Braden <[email-masked]>
Date: Wed, 13 Nov 2002 19:36:06 GMT

I finally found time to comment on the Framework draft.  Sorry this
comes so late.

A separate message contains interleaved detailed comments, issues,
questions, and disagreements.  This message distills out some general
comments.

The Framework document represents a substantial body of work with much
to recommend it.  I know from experience how much work is represented
here, and the authors deserve our praise and thanks.  However, I also
believe that considerable more work will be needed.

First, a somewhat philosophical comment.  My most general uneasiness
with the present document is that it seems at times to float in a
void.  It seems a bit too top-down in flavor at times, without enough
grounding in the real Internet issues.  This gets better through the
document, so that I generally liked sections 4, 5, and 6 much better
than the eaerlier sections.  It also seems a bit disconnected from the
significant previous history of Internet signaling.  Many of the
technical issues of Internet signaling have in fact been explored in
the IETF, principally by the RSVP working group (although not all of
the conclusions made it into the existing RSVP v1 RFCs).

Many readers will be familiar with at least the general concepts of
RSVP, and it would be very helpful if the document was explicit, at
least in a parenthetical way, about places where NSIS is taking a new
tack, as well as places where it is covering the same ground.  In a few
places, using existing terminology where it fits would also be
helpful.

Now more specific general comments ;-)

1.  I believe that the document would gain increased depth and
	credibility if it had a few more references to important and
	relevant academic papers.  Particular examples might include
	YESSIR, Lixia's multi-level model, or (a small selection out of
	the corpus of) papers about mobile resource reservations.

2. There is a lot of good material and specific discussion, but there
	is some redundancy.  It probably needs a serious hack
	with a text editor, moving blocks of text around and deleting
	redundant material. (see detailed comment message for examples.)

3. I would like to suggest that the only occurrence of the 4-letter
	term "NSIS" in this document should be in the combination
	"NSIS Working Group".  All other occurrences of NSIS should
	be replaced by something else ... e.g., "Internet signaling"
	or "signaling" or ... whatever works in the particular context.

	Another useful term is "suite", as in a "suite of signaling
	protocols".

	Curiously, the word "node" almost never occurs in this document,
	yet it is fundamental.  Signaling can be described abstractly,
	but that has to map into real messages sent between real
	nodes -- end systems, routers, and middleboxes.  This may be
	just a stylistic thing.

4. The document tends to say, "Oh, by the way, this is not *just* about
	QoS", and then shortly falls into QoS-oriented terminology.
	I think this is the wrong orientation.  It should rather be:
	"This is about all forms of path-related Internet signaling,
	such as QoS setup and control of middleboxes."

	A deeper consequence of this is the need to be quite precise about
	terminology, to make sure it is sufficiently general.

		What is the purpose of "signaling"? I generally use the
		Computer Sciency phrase, "to establish state in network
		nodes".  The document often uses the term "resource
		request" for roughly the same concept (though it is not
		consistent.)

	At first I thought "resource request" should be replaced
	because it is too QoS-specific.  However, it seems more in
	keeping with the existing document to simply define "resource
	request" in a general way as equivalent to setting up state,
	using a very general notion of what we mean by "resource".  I
	think this can be made to work, but it needs a careful
	paragraph in the Introduction and strict care to always use
	this term.  You will find a number of detailed suggested
	changes in this direction in my detailed comments.
 
5. At many points, the Framework document seems to assume a simplistic
	model of resource reservation -- that it is necessarily
	one-pass and can be achieved by a one-way flow of signaling
	packets along the data flow path.  This omits the potentially
	important cases that require two-pass algorithms, or those that
	use one-pass-with-advertising (e.g., the IntServ Guaranteed
	service.)  The WG should beware of simplistic
	assumptions.

	This shows up most directly in the terms NI and NR, whose
	semantics are sometimes confusing.  Of course, *I* prefer the
	abstractions p-src and p-dest that I introduced in my 2level
	document ;-), but perhaps NI and NR can be made to work.
	However, that will require careful definition and usage.  For
	example, RSVP v1 depends upon signaling in both directions,
	using both Path and Resv messages.  So, for RSVP v1, both
	sender and receiver act as both NI and NR.  Some of the
	discussion does not seem to encompass this generality.

6. The fundamental architectural picture in Figs 1 and 4 seems at
	first blush to be obvious, but the more I think about it,
	the more uncertain I am.

	The idea of a "co-located NI&NF" seems to conceptually define
	what you expect to be in an end system doing QoS signaling
	using the new protocol (and indeed that is exactly what RSVP v1
	assumed).  In particular, an Internet end system has to have at
	least a primitive routing/forwarding function, because it may
	be multihomed and/or have multiple first-hop routers.   Also,
	for QoS setup, at least, it is generally necessary to have an
	(inner-)RMF in the end system as well as in the routers.
	(as shown in figure 9, which contradicts Figure 1!)

	These considerations probably hold even if the NI is not an
	end system.  In fact, now that I think of it, it seems that
	there "co-located NI&NF" will be the normal case, except when
	a proxy is the NI.

	Iin practice the NI and NF functions will hopefully be only a
	single protocol entity in the end system.  You can DESCRIBE it
	logically as two connected conceptual boxes, but this may not
	be very helpful to the implementor or in detailed design.  In
	other words, the seemingly plausible picture conceals a deep
	issue of modularity and interface placement.

	Even if we decide that the figures as drawn at the best model,
	some discussion is needed about how this model maps into the
	real world.	

7. The path-coupled/path-decoupled dichotomy is not all there is.

	Thinking about this space, I was led to introduce a different
	dichotomy, "path-related" vs. "path-unrelated".  The NSIS
	WG is primarily focusing on path-related & path-coupled
	signaling, but some would like to also handle path-related &
	path-decoupled signaling.  However, there is a 3rd class
	of signaling that has no direct relationship to any path; I
	called this path-decoupled.  It might for example be used to
	configure routers in a domain.  This is still signaling, but
	not the kind we intend to do in NSIS.

8. The text tends to imply the model of a signaling message passing
	from NI to NR through NFs undisturbed, rather like IP packets
	passing through routers.  (See for example the first sentence
	of section 5.1)  In some cases this may be the wrong
	conceptual model.  In RSVP, signaling is best thought of as
	hop/hop; each hop propogates state in each direction, to keep
	certain invariants true.  Also, refresh messages are generated
	independently and asyncronously at each hop.  It is true that
	hop/hop action is forced by support for multicast, with its
	merging, so it may not be directly relevant to NSIS. However,
	there may be other signaling applications that will best be
	implemented as hop/hop signaling.

9.  Sections 5.1 and 7.2 (which are somewhat redundant) seem foggy to me.
	For one thing, an RMF may be specific to one or more signaling
	applications, and there may be many distinct RMFs in a single
	node.

	Also, Figure 4 (which is repeated as Figure 7) and Figure 8
	depict two quite different kinds to things [I would call them
	"entities", but you've used up that word ;-)], and it is not
	clear to me that you can usefully encompass both in a common
	abstraction.  I see two kinds of things: an inner-RMF, which is
	the interface to the local node's

	I see "inner-RMFs" (Figs 4 & 7) that are local interfaces to
	the traffic control and admission control mechanisms of the
	forwarding plane.  The WG should look into how an inner-RMF
	relates to the FORCES work of the IETF. 

	Note that when an inner-RMF is a server, it may supply
	information to the NE as well as accept control state.
	Examples are admission control decisions and the Adspec
	machinery of RSVP v1.

	Then there are "outer-RMFs" (Figure 8), which seem to have
	quite different characteristics. This section to be an attempt
	to bring the bandwidth broker under the NSIS umbrella, but
	this may/may not fall into our chartered area. 

	Finally, it is far from obvious to me that the NF/RMF interface
	corresponds to an SLA.  
_____________________________________
Bob Braden
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 14 Nov 2002 11:41:40 +0100

> 	discussion does not seem to encompass this generality.

Bob,

I think we cover 80% of the relevant cases of reservation styles with a 
simple one-pass scheme. Concerning the NI/NR terms. I like the NI, because 
it does not say something about who is performing reservations, but it is 
driven by somebody initiating the whole thing.

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

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
Phone: +49 (0) 6221 905 11 29
personal home page: http://www.brubers.org/marcus