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

From: [email-masked]
Date: Thu, 14 Nov 2002 09:11:23 +0100

Hi Bob,

Thanks for your comments. I have some remarks/questions inline.

Thanks,
Sven

Bob Braden <[email-masked]>@ietf.org on 13/11/2002 20:36:06

Sent by:  [email-masked]

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.

[Sven] Would it be improved if we were more stringent about the NTLP/NSLP
separation throughout the document. More emphasis is placed on this in the
current version but maybe not enough throughout the text. I believe the
framework should talk about both layers. I also think that the focus on the
hop-by-hop aspect may be different for both layers (more for NTLP and less
for NSLP that is). Assuming that NSLP is what contains the description of
what actually needs to be reserved or done, it is reasonable to describe
the interaction with RMF more from the NSLP viewpoint.

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.

[Sven] I agree. On the other hand, if an RMF is specific to a signalling
application, the complete picture could be assembled from many of the
current picture in parallel.

     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

[Sven] The idea was to clarify that there are indeed to different types of
interactions with the RMF. On the one hand, the RMF may just be a server
which assists in performing admission control for locally controlled
resources (what you call the inner-RMF). On the other hand, it may trigger
a new layer of (local) NSIS signalling. This is what you call the outer-RMF
and what is depicted in figure 8. The picture may look a bit 'centralized'
but it essentially expresses NSIS nesting where the RMF can be either
client or server.

     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.

[Sven] I fully agree.

     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.

[Sven] It does cover bandwidth brokers but it is certainly not restricted
to that. There is no argument that bandwidth brokers are currently not the
priority for the NSIS WG but it is also agreed that the framework
should/may have a somewhat broader scope.

     Finally, it is far from obvious to me that the NF/RMF interface
     corresponds to an SLA.

[Sven] I think it depends on where you see the admission control. If you
see this as part of or colocated with the NF (i.e. handling of NSLP) then
you can think of the RMF as providing an amount of capacity (e.g. the link
bandwidth for a certain class of service) in which the NF does admission
control.
_____________________________________
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: Bob Braden <[email-masked]>
Date: Thu, 14 Nov 2002 22:47:10 GMT

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

John,

I suspect that if you sat down to design a real implementation, you
would soon discover the practical consequences of the fundamental
model.

Which brings up an interesting point -- when the RSVP WG started, most
(but not all!) of the research and simulation had already been done on
the protocol, and it was only necessary to get the engineering details
right in the WG. (Of course, the process of engineering and documenting
led us to discover a few unsolved research problems, so there was a
circular process.)  Concurrent with the WG, we were building, testing,
and demonstrating a prototype, and that work fed strongly back into the
WG efforts.  I worry that NSIS is too top-down; there is not enough
"running code".

...

  *> 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?) 

"Arbitrary violence" -- OK ;-)

(Either side of what?  Either side of a node on the path? I thought the
answer was "no", since your framework allows different NSLPs at
different points along the path.  You might seldom want to mix
protocols, but it does not seem outrageous.  In fact,the flexibility
might allow you to divide a big, complex, multipurpose signaling
application (NSLP) into smaller more special-purpose protocols and use
each where appropriate.)

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

Important point: I think that the CSTP/NSLP layer should not make ANY
assumption about message patterns, while a specific ULSP/NTLP must
necessarily make an assumption, and different ULSPs/NTLPs may make
different assumptions about message patterns.

Right?

Bob

---

From: Bob Braden <[email-masked]>
Date: Thu, 14 Nov 2002 22:55:19 GMT

*> 
  *> 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.
  *> 
  *> [Sven] Would it be improved if we were more stringent about the NTLP/NSLP
  *> separation throughout the document. More emphasis is placed on this in the

Yes, I believe so.

  *> current version but maybe not enough throughout the text. I believe the
  *> framework should talk about both layers. I also think that the focus on the
  *> hop-by-hop aspect may be different for both layers (more for NTLP and less
  *> for NSLP that is). Assuming that NSLP is what contains the description of
  *> what actually needs to be reserved or done, it is reasonable to describe
  *> the interaction with RMF more from the NSLP viewpoint.
  *> 

Yes, I think I agree.

  *> 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.
  *> 
  *> [Sven] I agree. On the other hand, if an RMF is specific to a signalling
  *> application, the complete picture could be assembled from many of the
  *> current picture in parallel.
  *> 
  *>      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
  *> 
  *> [Sven] The idea was to clarify that there are indeed to different types of
  *> interactions with the RMF. On the one hand, the RMF may just be a server
  *> which assists in performing admission control for locally controlled
  *> resources (what you call the inner-RMF). On the other hand, it may trigger
  *> a new layer of (local) NSIS signalling. This is what you call the outer-RMF
  *> and what is depicted in figure 8. The picture may look a bit 'centralized'
  *> but it essentially expresses NSIS nesting where the RMF can be either
  *> client or server.

We are having an agreement, although the text needs some work to say
more clearly what you just said.  There is an issue that is partly (but
not entirely) just expository: are the "two different types" should be
given the same name "RMF".  I think I could argue that they are so
different that it would be clearer to all if they had different names.

  *> 
  *>      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.
  *> 
  *> [Sven] I fully agree.
  *> 
  *>      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.
  *> 
  *> [Sven] It does cover bandwidth brokers but it is certainly not restricted
  *> to that. There is no argument that bandwidth brokers are currently not the
  *> priority for the NSIS WG but it is also agreed that the framework
  *> should/may have a somewhat broader scope.

I agree with that, and I think the material on Figure 8 is just fine and
belongs here. 

  *> 
  *>      Finally, it is far from obvious to me that the NF/RMF interface
  *>      corresponds to an SLA.
  *> 
  *> [Sven] I think it depends on where you see the admission control. If you
  *> see this as part of or colocated with the NF (i.e. handling of NSLP) then
  *> you can think of the RMF as providing an amount of capacity (e.g. the link
  *> bandwidth for a certain class of service) in which the NF does admission
  *> control.

I agree that there is a problem here with modularity and interfaces.
I wonder whether the FORCES work might give us some useful guidance
here?

Bob

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 14 Nov 2002 23:44:19 -0000

Hi Bob,

> -----Original Message-----
> From: Bob Braden [mailto:[email-masked]]
> Sent: 14 November 2002 23:47
> To: [email-masked]; [email-masked]; Hancock, Robert
> Subject: RE: [NSIS] General comments on draft-ietf-nsis-fw-01.txt
> 
> 
>   *> 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.
> 
> John,
[reh] i'll answer anyway ;-)

> would soon discover the practical consequences of the fundamental
[reh] I'm assuming other implementors are happy to structure their work without being constrained by the model (I certainly used to be). What constraints on the protocol do you see?

> WG efforts.  I worry that NSIS is too top-down; there is not enough
[reh] I half agree, but this is the way we are encouraged to work these days. I am sure if someone turned up in the WG at this stage saying 'here's my implementation' someone would protest anyway.

> application (NSLP) into smaller more special-purpose protocols and use
[reh] Precisely, and [personally] I can see significant advantages in being able to do this e.g. in the QoS signalling case.
More generally, at some stage we could consider the question of whether we expect there to be lots of simply NSLPs or a few complicated ones.

>   *> 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.
> 
[reh] Agreed, modulo changing NSLP<-->NTLP in the previous paragraph. (Although this is probably not the current framework working assumption and needs discussion - I think our starting point was more "There's a set of basic NTLP messages, whose payloads are specialised for different purposes." I could - just - see that working for QoS but not for everything else now on the table.)

The only exception I can see might be that a very lightweight NSLP could elect to use the NTLP in a purely forwards-along-the-data-path mode, to really minimise network state storage requirements. Is this a useful optimisation?

> Bob
robert h.

---

From: [email-masked]
Date: Fri, 15 Nov 2002 08:44:01 +0100

Hi Bob,

Thanks for your comments. I think we can summarize the outcome as:
- clarify NTLP/NSLP in the context of RMF (according to the discussion
below)
- clarify the different types of RMF interactions, probably requiring
different names for both types
- link to  FORCES

CU in Atlanta,
Sven.

Bob Braden <[email-masked]> on 14/11/2002 23:55:19

To:   [email-masked], Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:   [email-masked]
Subject:  Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt

  *>
  *> [Sven] Would it be improved if we were more stringent about the
NTLP/NSLP
  *> separation throughout the document. More emphasis is placed on this in
the

Yes, I believe so.

  *> current version but maybe not enough throughout the text. I believe
the
  *> framework should talk about both layers. I also think that the focus
on the
  *> hop-by-hop aspect may be different for both layers (more for NTLP and
less
  *> for NSLP that is). Assuming that NSLP is what contains the description
of
  *> what actually needs to be reserved or done, it is reasonable to
describe
  *> the interaction with RMF more from the NSLP viewpoint.
  *>

Yes, I think I agree.

  *> 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.
  *>
  *> [Sven] I agree. On the other hand, if an RMF is specific to a
signalling
  *> application, the complete picture could be assembled from many of the
  *> current picture in parallel.
  *>
  *>      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
  *>
  *> [Sven] The idea was to clarify that there are indeed to different
types of
  *> interactions with the RMF. On the one hand, the RMF may just be a
server
  *> which assists in performing admission control for locally controlled
  *> resources (what you call the inner-RMF). On the other hand, it may
trigger
  *> a new layer of (local) NSIS signalling. This is what you call the
outer-RMF
  *> and what is depicted in figure 8. The picture may look a bit
'centralized'
  *> but it essentially expresses NSIS nesting where the RMF can be either
  *> client or server.

  *>
  *> [Sven] It does cover bandwidth brokers but it is certainly not
restricted
  *> to that. There is no argument that bandwidth brokers are currently not
the

  *>
  *>      Finally, it is far from obvious to me that the NF/RMF interface
  *>      corresponds to an SLA.
  *>
  *> [Sven] I think it depends on where you see the admission control. If
you
  *> see this as part of or colocated with the NF (i.e. handling of NSLP)
then
  *> you can think of the RMF as providing an amount of capacity (e.g. the
link
  *> bandwidth for a certain class of service) in which the NF does
admission
  *> control.

Bob

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 15 Nov 2002 12:07:50 +0100

Hi Bob

I think that I agree with many of your comments.
However, it will be great if we could discuss and agree 
on the terminology regarding NI, NF and NR.
Due to this terminology you probably got confused 
with the definition of the sender and receiver initiated modes.

Related to the definition of sender/receiver initiated modes,
we wanted to actually say the following:
* sender initiated: is the mode where the sender of the data path
  is initiating the procedure of installing the reservation 
  (requested resources) states
* receiver initiated: is the mode where the receiver of the data 
  path is initiating the reservation (requested resources) states.

Best regards,
Georgios

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 15 Nov 2002 12:24:44 +0100

Hi Sven and Bob

One important issue for discussion that actually severely impacts the 
NTLP (or CSTP) and NSLP (or ULSP) model is related to the dependency
between the (NSIS) protocol requests and the creation (maintenance) of 
NTLP and NSLP states.

For example:
1) One per flow request into a node creates one per flow state 
  at NSLP level and one per flow state at NTLP level; 

2) One per aggregated request creates one per-aggregate state 
  at the NSLP level and one per-aggregate state at the NTLP level;

3) One per-flow or one per aggregate request belonging to one traffic class
   is only modifying the traffic class state in the NSLP and it does not need 
   to create and maintain a state in the NTLP. I define a traffic class as 
   a state associated to an independent number of flows that are belonging 
   to the same traffic class;

Best Regards,
Georgios

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: vrijdag 15 november 2002 8:44
To: Bob Braden
Cc: [email-masked]; [email-masked]
Subject: Re: [NSIS] General comments on draft-ietf-nsis-fw-01.txt

Hi Bob,

CU in Atlanta,
Sven.

  *>

Yes, I believe so.

Yes, I think I agree.

  *>

  *>

Bob

---

From: Bob Braden <[email-masked]>
Date: Fri, 15 Nov 2002 16:49:54 GMT

*> [reh] Agreed, modulo changing NSLP<-->NTLP in the previous paragraph.

Damn, sorry, you're right.  That is one problem I have with the
NSLP/NTLP terminology... my senior brain gets them confused! ;-)

Bob

---

From: Bob Braden <[email-masked]>
Date: Fri, 15 Nov 2002 17:53:46 GMT

*> 
  *> For example:
  *> 1) One per flow request into a node creates one per flow state 
  *>   at NSLP level and one per flow state at NTLP level; 
  *> 
  *> 2) One per aggregated request creates one per-aggregate state 
  *>   at the NSLP level and one per-aggregate state at the NTLP level;
  *> 
  *> 3) One per-flow or one per aggregate request belonging to one traffic class
  *>    is only modifying the traffic class state in the NSLP and it does not need 
  *>    to create and maintain a state in the NTLP. I define a traffic class as 
  *>    a state associated to an independent number of flows that are belonging 
  *>    to the same traffic class;
  *> 
  *> Best Regards,
  *> Georgios

Georgios,

I believe that the short answer to your question is that my proposal
already gives you what you want.

I believe that your case 3) is exactly the "SendInfo" primitive
of my API: the SAPU is transmitted reliably but it is not treated
as soft state.  Therefore the receiving CSTP acknowledges it and
demuxes it to the local ULSP module, but the CSTP does not maintain
a copy or any record of the state for timing it out.

So I believe that we have already provided you the facility for a
both "statefull" and "stateless" CSTPs (to use the term on your slides.)
BTW, it was absolutely my intent that the 2level signaling model
should be able to provide the functional organization in your
"Architecture" slide, with its acknowledgment of the core/edge
distinction for signaling.

The other aspect of your slide, PDR vs PHR, harks back to the
discussion that Robert and I have just been having -- how fine-grained
should ULSPs be?  I can imagine defining a single ULSP that exhibits
either PDR or PHR behavior depending upon where it is installed.
Alternatively,PDR and PHR form a pair of distinct but interrelated
ULSPs.  Thinking through the implications in this particular case
might give us some insight about the general design issue.

Finally, note that there is really no difference between your cases (1)
and (2) above,  I defined a "flow" to be of any desired granularity,
from a microflow to a fully aggregated flow.  Furthermore, the CSTP I
defined does not even really know about flows, it really only knows
about sending and receiving signaling messages and about timing out
soft state.  The semantics of flow identification and aggregation are
known only to the ULSP.
[There may be some issues about the specific division of functionality
I chose between CSTP and ULSP.  My choice seemed to be forced by my
desire to provide a common soft-state mechanism in the lower layer, and
there were subtleties having to the interaction with routing.  There is
a design issue that I have been reconsidering... whether in fact the
CSTP *should* know about flows... but that should be the subject of a
different message.]

Thanks,

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Fri, 15 Nov 2002 19:06:06 GMT

*> Hi Bob
  *> 
  *> I think that I agree with many of your comments.
  *> However, it will be great if we could discuss and agree 
  *> on the terminology regarding NI, NF and NR.
  *> Due to this terminology you probably got confused 
  *> with the definition of the sender and receiver initiated modes.
  *> 
  *> Related to the definition of sender/receiver initiated modes,
  *> we wanted to actually say the following:
  *> * sender initiated: is the mode where the sender of the data path
  *>   is initiating the procedure of installing the reservation 
  *>   (requested resources) states
  *> * receiver initiated: is the mode where the receiver of the data 
  *>   path is initiating the reservation (requested resources) states.
  *> 
  *> Best regards,
  *> Georgios
  *> 

Georgios,

Pardon if I am being obtuse, but this distinction does not seem to
capture the difference.  In the RSVP case, state is being installed in
both directions: path state is installed downstream and reservation
state is installed upstream.  Hence, you would have to say that RSVP is
both sender- and receiver-initiated.

Perhaps the confusion comes because we are not making a necessary
distinction between a specific signaling operation and the signaling
application's effect.  The effect of RSVP is to install
"receiver-initiated resource reservations", but RSVP achieves this
effect using bi-directional signaling operations.

For the purposes of the Framework, I suggest we want to use NI and NR
to define a signaling operation.  Then, indeed RSVP would make both
sender and receiver the NI and the NR. The text needs to make clear
that "Initiator" in NI is intended in this very specific sense, not to
be confused with the higher-level semantic effect that people usually
call "sender-initiated" or "receiver-initiated".  I suggest that we
instead refer to "upstream" and "downstream" signaling operations.

Does this make sense?

Bob

  *> 
  *> -----Original Message-----
  *> From: Bob Braden [mailto:[email-masked]]
  *> Sent: woensdag 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