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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 14 Nov 2002 00:21:20 -0000

Hi Bob,

Thanks for the detailed review (when I get at it).

I think 1/2/3/4/7/9 are all probably quite reasonable (and are basically presentation related).
I think the point you raise in 6 is interesting, which I and others agonised a lot about in this and previous non-framework documents. Eventually I gave up worrying because I couldn't see a practical impact. If we can find one, it should help us work out which alternatives to emphasise. 
The point in 8 is partly related. I have generally come from a perspective of thinking that an internal node could do arbitrary violence to the messages (do we even assume it is the same signalling application protocol either side?) but maybe this doesn't come across (and quite possibly isn't what other people think).

I think the most important point you raise is (5) - what message patterns we should support/assume. I'd really like to see some views about the range of options here.

Cheers,

Robert H.

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: 13 November 2002 20:36
> To: [email-masked]
> Cc: [email-masked]
> Subject: [NSIS] General comments on draft-ietf-nsis-fw-01.txt
> 
> 
> 
> 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
> 
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Melinda Shore <[email-masked]>
Date: Thu, 14 Nov 2002 10:01:35 -0500

On point 6 (message flows), complicating features include
whether or not part of the signaling problem you're trying
to solve include topology - that is to say, some NFs are
more interesting than other NFs, based on their topological
relationship.  The most obvious cases of that would be ones
in which you're asking something in particular of an
outermost NF but you don't have any way of knowing where
that is and you're asking the signaling protocol to handle
it for you.  For example, in the case of NAT, you're
using the signaling protocol to do 1) installation of NAT
table state, and 2) reporting on installed state (so that an
application that uses embedded addresses can know the
correct address with respect to the application peer).  In
the case of tunnel endpoints (a subset of security gateways,
for example, but they may be other types of tunnels) you
probably want to find the furthest tunnel endpoint along
the path, but you may be interested in finding the closest,
or the one that has the most appropriate set of other
(non-topological) attributes.

Note that these have slightly different messaging
requirements.  In the case of NAT it may be sufficient to
store state in a forward direction and then have the
receiver return a result message.  In the case of signaling
gateways, however, each NF can't store state in a forward
direction because (unlike NAT) no decision can be made about
who gets to terminate the tunnel until a complete picture of
the topology/capabilities/whatever is accumulated.

Melinda