Subject: Re: [NSIS] RE: What's in the charter of NSIS

From: Bob Braden <[email-masked]>
Date: Fri, 17 May 2002 16:47:07 GMT

Lixia wrote:

...

  *> 
  *> But I cannot help throwing a comment on this specific one: NSIS stands for
  *> "Next Step in Signaling", not next step in QOS.
  *> 
  *> I personally do NOT think a signaling protocol should involve itself into
  *> the definitions of what QOS requirements should be.
  *> QOS requirements may change over time, yet one wishes that the signaling
  *> protocol, which is used to carry the QOS requirements, does NOT have to
  *> change.
  *> 
  *> Besides, there WILL be other uses of a signaling protocol other than QOS
  *> need.  My understanding is that NSIS is chartered to look into the need for
  *> a signaling protocol, NOT the QOS requirement.
  *> 

I want to say "amen" to all of that.

The original message from Gary Kenward included, "... QoS
specifications such as the Tspec." The Tspec is not by itself a QoS
specification.  In fact, even talking about "a QoS specification" is to
oversimplify a complex process, which may involve two passes, one pass
with advertising, etc.  There are many possible QoS models; int-serv
chose just two of them.  And NSIS should choose NONE of them; a
next-generation signaling protocol should be able to handle any future
model.

This observation, together with Lixia's comment, leads me to the
realization that RSVP may have had the modularity wrong (and NSIS might
pay attention to this point).  RSVP design and specification may ahve
talked too much about int-serv specific things like Tspecs.  We should
instead have defined RSVP strictly in terms of transporting opaque QoS
objects upstream and downstream, and applying some model-specific
algorithms at merge and branch points.  The definition of these objects
and algorithms would then be completely contained in documents that
define QoS models.

Our vision was imperfect when we began the Internet integrated services
work in 1993.  If we had gotten the modularity better, we would perhaps
have avoided some of the immense amount of misunderstanding that is
still current about Internet QoS issues.

BTW, see draft-braden-2level-signal-arch-00.txt for a glimmer of a
better modularity.

Bob Braden

  *> My personal 2 cents,
  *> Lixia
  *> 
  *> 
  *> _______________________________________________
  *> 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: Fri, 17 May 2002 13:08:19 -0400

At 04:47 PM 5/17/02 +0000, Bob Braden wrote:
>talked too much about int-serv specific things like Tspecs.  

I've written a document describing the use of RSVP for firewall
traversal and NAT traversal (which I'll be sending to the secretariat
next week) and another describing the use of of RSVP for IPSec
tunnel endpoint discovery and rudimentary SDB management ("don't
encapsulate this").  The latter will probably not be submitted
in its current form but was interesting to write.

What I found was 1) the RSVP protocol machinery is *extremely*
well suited to addressing generic middlebox problems, and 2) exactly
what you're saying - some of the required data are inapplicable
to generic middlebox problems (this may apply to the rich variety
of reservation styles, as well).

I think that a number of the proposed middlebox "solutions" share
the same problem, and that is that by violating protocol layers
to have, say, applications try to influence network-layer services
you're introducing some nasty topological problems, that you can
avoid by using a protocol like RSVP.  As a sort of a side note,
one of the principal anti-RSVP arguments, resource utilization,
doesn't apply to the middlebox problem because the middleboxes in
question [firewall, NAT] tend to be very highly stateful and RSVP
would tend to be manipulating existing state rather than introducing
new state.

Melinda