Subject: RE: [NSIS] An analysis of "Analysis of the RSVP Protocol"

From: "Greis Marc (NRC/Dallas)" <[email-masked]>
Date: Mon, 10 Dec 2001 14:17:45 -0600

Hi Bob,

> Of course I am partisan about
> RSVP, but this Draft heaps on more of the nonsense that has been
bandied
> about. 

Believe it or not, but I actually agree with this statement to a large
extent. The main purpose that I see in this draft is to actually write
down the "nonsense that has been bandied about" so that there is a
chance to refute it.  Until now, many of the (unjustified)
concerns/complaints about RSVP exist merely as hearsay. I thought it
would be benefical to gather these rumors to make it easier to extract
the truth from them, as small as it may be.

> Hmmmm.  The title is "Analysis...".  An "unbiased summary" of RSVP
> would include its strengths, which are considerable, as well as its
> purported weaknesses.

I agree again. This is currently mostly a "What is said to be wrong"
draft, rather than a full analysis. When I claim to be unbiased, I am
only unbiased in that respect that I added points to the draft that I
don't agree with, simply to allow the WG to shoot these points down.
That may seem strange, but as I stated before, I see it as an
educational exercise of sorts. In the end, I'll leave it to the WG chair
to decide if that educational exercise is useful or a waste of time.

I can see how the content of the draft does not seem to match the title
at this point. That is supposed to change, as the considerable strengths
(and I do agree that they are considerable) are intended to be included
at a later stage.

> As a complaint against RSVP this is simply nonsense, for several
> reasons.  RSVP was never intended to be used in the core of the
> network, where scalability is a serious issue.  Intserv over diffserv
> in the core is what was intended, and it is now defined (although you
> have no reference to it.)  Why must we keep beating this horse?

To ensure that it is dead. If I find out that it's not necessary to beat
the horse any further, I'll be happy.

> The proxy draft is not clear to you?  (It isn't clear to me, either,
> I must admit).

The idea was to start out from RFC 2205 and then to throw in the rest of
the "RSVP extension suite" later. Note that this draft is intended to be
a starting point, not the end of all wisdom. It is after all a draft.

> So, you need a different service model; define it.  (There is a
> tendency for people to wave their arms and insist on "QoS" without
> undertaking the hard intellectual work of defining a service model.
> "And then QoS magic happened... everything got better!"

Well, first there has to be a consensus that a new (or in this case, I
would rather say extended) service model is needed. I prefer to identify
the need before jumping in with a conclusion. If everyone agrees that a
new/extended service model is needed for certain networks, then I think
we have made one step towards finding the solution.

There are several of your comments which I did not directly reply to, as
my answer would have been close to "I agree" in most cases. However,
this is the kind of comments I was actually looking for, i.e. what in
this draft would have to go, what is just incorrect, what needs to be
extended.

Marc

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2001 16:53:00 -0800 (PST)

Greis Marc (NRC/Dallas) writes:
 > extent.

   FWIW, I read this draft in pretty much the same
   light as Bob. That is, it dredges up all kinds of
   things that RSVP does already, and makes it look
   as if they are problems. I don't really think our
   job here is myth destroyers or evangelicals. Relisting
   all of the requirements, regardless of motiviation,
   does have a good chance of being misinterpreted for
   one, and excruciatingly overwrought for another.
   Crispness is our friend.

		MIke