Subject: Re: [NSIS] on-path versus off-path discussion

From: Bob Braden <[email-masked]>
Date: Thu, 24 Oct 2002 18:56:12 GMT

*> 
  *> There definitely are some pro and cons for both approaches. See "On path 
  *> and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt for a 
  *> discussion on some of them. Furthermore, there are some implementations 
  *> (experimentqal and products) available for centralized QoS provisioning.
  *> 

Well, so I just read this draft, and I don't quite get it.  I am actually
prepared to be persuaded about the suggested mixed model, although I note
that some of the detailed arguments against path-coupled signaling seem
to me of the form, "If you do something dumb, it won't work".

However, the discussion seemed to gloss over a basic issue.  I hope you
can explain it to me.

	The purpose of signaling is not just to use up bandwidth, I
	hope; it actually exerts some control function on the routers
	along the path for some set of data packets.  We customarily
	summarize that by saying that the purpose of signaling is to
	establish state in routers (and we mean of course the routers
	on the data path!).  So suppose you have a set of distinct
	off-path signaling nodes that are happily chatting with each
	other doing path=decoupled signaling.  Presumably, each of
	these control nodes then somehow sends control information to
	the routers in its own flock, to set up filters, packet
	queueing parameters, etc., to obtain the desired QoS.  My
	question is, how is this off-path/on-path local signaling
	done?  And doesn't this add a whole new dimension of
	complexity and fragility??

Looking forward to understanding,

Bob Braden

  *> We need to clarify what the way forward is concerning off-path signaling. 
  *> On-path is in the charter of the NSIS WG. Additionally, there are a number 
  *> of issues for clarifying what on-path includes. In certain cases the 
  *> boundary is not straight forward.
  *> 
  *> Currently, there seam to be 3 positions in the community:
  *> 1) Forget about off-path, nobody will use it and it is architecturally 
  *> problematic in IP networks
  *> 2) Form a new WG taking care of the off-path issue completely independent 
  *> of NSIS.
  *> 3) Require NSIS to work for on- and off-path signaling, because data 
  *> objects to be carried by the protocol should basically be the same in both 
  *> cases, and a soft-state approach is worth for off-path as well.
  *> 
  *> Current draft dealing with some of the issues
  *> "On path and off path signaling for NSIS", draft-schelen-nsis-opopsig-00.txt
  *> 
  *> Discussion list:
  *> mailing list is called "nsobs", which stands for "Next Steps in Out-of-Band 
  *> Signaling" is Majordomo list at ccrle.nec.de
  *> 
  *> To subscribe send e-mail to [email-masked] with subscribe in 
  *> the body.
  *> 
  *> To send E-Mail to the list use [email-masked]
  *> 
  *> 
  *> --------------------------------------
  *> 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
  *> 
  *> --------------------------------------
  *> 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
  *> 
  *> 
  *> _______________________________________________
  *> 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: Roland Bless <[email-masked]>
Date: Sat, 26 Oct 2002 23:22:13 +0200

> Well, so I just read this draft, and I don't quite get it.  I am actually

Currently, a new version of the draft is prepared, hopefully with 
some clearer structure and discussion.

> prepared to be persuaded about the suggested mixed model, although I note

The basic idea of a "combined" model is that an NSIS protocol should 
be flexible enough to allow both kinds of signaling without causing 
real drawbacks for one particular solution. It should work flawlessly
with path-coupled signaling, but also allow to add path-decoupled
signaling later without the need to redefine the basic protocol format.

> 	on the data path!).  So suppose you have a set of distinct

I'm not sure why signaling must always establish state in routers.
Wouldn't it be more general to say that signaling is to do something
in some sort of "control" plane, e.g. perform admission control, reserve
resources, install or update states, change configurations, etc... 

Typically, in a transit DiffServ domain I can let routers just do
their packet forwarding and only need to adapt the profiles in
boundary routers once a while. If a BB takes care of admission control
etc., there is no need to install state in core routers...
Furthermore, you'll need some possibility to store persistent state
for managing policy-based admission control and accounting. Routers
are usually not able to store persistent states (except their basic
config). So why not take all burdens of control processing off the
routers and let a real powerful system do the control job?

> 	complexity and fragility??

Usually, it is a local decision how the signaling to routers
will be done, so autonomy of a domain is kept. However, there 
are many possibilities, such as using COPS (I know that opinions
will diverge here..), SNMP or even CLIs. Basically, you need a 
protocol that will be able to transport configuration information,
fast, robust and reliable.  Maybe we need something new.
 
> Looking forward to understanding,

I hope it helps a little bit,
 Roland

-- 
Roland Bless -- e-Mail: [email-masked] WWW: www.tm.uka.de/~bless
Institute of Telematics, University of Karlsruhe, Germany  
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Bob Braden <[email-masked]>
Date: Sat, 26 Oct 2002 18:55:19 -0700

>resources, install or update states, change configurations, etc...

Unnh,,, it sets some bits somewhere in the network, in fact, somewhere
on the data path, right?  In the Internet
model, everything "in the network" is a router, but I don''t need to insist
on that. But signaling DOES set control bits SOMEWHERE  in the
network, right?  Those bits are STATE.  QED. (else it's not signaling?)

>etc., there is no need to install state in core routers...

I didn't say WHICH  routers.  But the "core routers" are either
statically provisioned or else there is some sort of signaling
going on to set up their state

>routers and let a real powerful system do the control job?

Well, the statement "real powerful system" seems to ignore
Moore's law and the current state of the technology.  A high-end
router may have processing power equal to any specialized
control processor.  So your statement seems like a bogus argument.
However, it is fundamentally the wrong argument for NSIS -- the right
argument would be about architecture, not current technology.

>will be done, so autonomy of a domain is kept. However, there

You mean there will be no interoperable standards? Pooh.

>fast, robust and reliable.  Maybe we need something new.

Yes, and it is signaling.  So path-decoupled signaling has
added a new source of complexity and fragility, as I
suspected.

Bob Braden

---

From: Roland Bless <[email-masked]>
Date: Sun, 27 Oct 2002 10:46:33 +0100

Hi Bob,

> network, right?  Those bits are STATE.  QED. (else it's not signaling?)

Ok, SOMEWHERE has to be state installed, but not in every router
along the data path (which was probably my misunderstanding here)
for every signaling process.

> going on to set up their state

Yup.

> control processor.  So your statement seems like a bogus argument.

Sure, routers are fast powerful with respect to data forwarding
tasks, which is really nice. The argument aimed at a separation of
data forwarding and some more complex control functions which can be
outsourced to other entities (and which actually were, e.g., for RSVP 
policy-based admission control).

> argument would be about architecture, not current technology.

Sorry, what I meant was that a separation of control plane and
forwarding plane, which is an architectural issue. Let routers have a
minimal set of control functions and let other entities perform more
complex control functions. The separation of forwarding and routing
algorithms within routers is one example where separation worked
quite well and added the necessary flexibility.

> You mean there will be no interoperable standards? Pooh.

No, I didn't say they shouldn't be interoperable. It makes perfectly
sense to have non-vendor specific protocols for configuration such as
SNMP or COPS (although, in practice the CLI interface is still widely
used for actual router configuration). It is more in the spirit of
flexibility as envisioned in the DiffServ architecture.  For instance,
as a provider you're free to choose how you realize PHBs, which DSCPs
you use for them and how you actually provide a PDB.  So as a first
step a provider may choose his preferred way of configuration that
works for him at best. This will usually not influence inter-domain
signaling, and thus, interoperability at inter-domain level.  NSIS
currently doesn't deal with the question of how QoS is provided within
a domain, different approaches should be possible, as well as
applications other than QoS.

> added a new source of complexity and fragility, as I

Yes, it is some sort of signaling, but whether it's good or bad depends
on the view. If we outsource some more complex functions from routers,
we'll have to use an interface for the lower level control
functions. With SNMP and COPS two such basic interfaces exist.
Basically, such a design adds flexibility, but not necessarily
fragility if we engineer prudently.

Regards,
 Roland

---

From: "Marcus Brunner" <[email-masked]>
Date: Sun, 27 Oct 2002 17:33:19 +0100

Roland, Bob,
[...]
> signaling later without the need to redefine the basic protocol format.

Probably, I got too much confused about the whole discussion myself. But isn't
the main, and probably only difference, the interaction with routing?

I think the question boils down to whether an NSIS protocol should "hard code"
the use of IP routing/forwarding state or whether we allow also other
routing/forwarding mechnisms to be used for signaling. 

> resources, install or update states, change configurations, etc... 

IMHO it is all about state. But NSIS should care about state setup along a set
of nodes. Setting up state/config/etc via management protocols is more
client-server type of state setup.

Marcus

[...]
-------
Marcus Brunner
Network Labs
NEC Europe Ltd
Heidelberg, Germany

E-Mail: [email-masked]
WWW: www.brubers.org/marcus
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Bob Braden <[email-masked]>
Date: Tue, 29 Oct 2002 19:07:30 -0800

>the main, and probably only difference, the interaction with routing?

I said it a little differently in an earlier message -- it is a question of
whether or not the signaling is performed by a network entity that has an
IP address different from the IP address of the corresponding router.
But I suspect that is just another way to say "interaction with routing".

>routing/forwarding mechnisms to be used for signaling.

My answer is: "yes and no""!  I suggest that the CSTP level of the two-level
model should be general enough to support either path coupled or path-decoupled
signaling.  However, when NSIS considers developing an ALSP for QoS signaling,
I have the serious doubts I expressed previously about the architectural
wisdom of path-decoupled operation.  I hope the WG will at least require a
convincing technical argument (which I have not yet heard) in favor of the 
path-
decoupled model before including it in the (first) ALSP.

Thanks,

Bob Braden