Re: hop-by-hop and router alert options [Re: Question about use of RSVP

Pekka

While it is clear your distaste for RSVP, you haven't stated anything other 
than handwave why RSVP is so bad ("in the first place"). You mention there 
were mistakes and a BB will fix them, but you don't list a set of mistakes 
RSVP made for folks to digest. I don't know if you think they are so 
obvious you don't have to state them or you don't want to list them for 
whatever reason.
Humor me (and a few others here) with a few listed mistakes you believe 
RSVP made in its design, with how you would redo them (either with a BB or 
just a better RSVP design).
Without this, you are just ranting without substance to me - as I cannot 
glean anything real from your messages other than your distaste of RSVP in 
favor of a Bandwidth Broker...
At 12:21 AM 8/13/2004 +0300, Pekka Savola wrote:
> Inline..
>
> On Thu, 12 Aug 2004, David R Oran wrote:
> > > I question the usefulness of path-coupled signalling beyond a certain
> > > point in the network.  Dean Anderson voiced them pretty well in the
> > > original thread about RSVP -- it just doesn't seem to make any sense
> > > beyond a very closed environment (like the first hop) -- and in that
> > > case, you should be able to use another kind of signalling as well.
> > >
> > > If we don't learn anything of the mistakes we did with RSVP, we're
> > > bound to repeat them.
> >
> > First, we have to agree on what the mistakes were :-)
>
> Of course.  Then why this wasn't the first thing NSIS did after going
> for on-path signalling, or didn't I just manage to find it?
>
> I really really hope that there has been a problem statement...
>
> > > For example, has the design clearly restricted itself to the first or
> > > the last hop, or within the first couple of hops?
> >
> > No. Here's one counter-argument. Enterprise networks tend to have
> > dumb-bell topologies, where the bottleneck links are in the interior
> > rather than at the edges (exactly the opposite of serivce provider
> > networks). They have meshes of 100meg+ all over each site, but the
> > sites are interconnected with some service (like MPLS VPN, frame relay,
> > etc.) which is expensive and often with very limited bandwidth
> > (sometimes sub-T1). These links are not necessarily all that easy to
> > identify in the topology, because for reliability enterprises configure
> > mulitple routers and backup links. There is strong demand for
> > flow-granularity admission control on such links, and an end-to-end
> > model works better because site-to-site flows can swamp both the uplink
> > at one end and the downlink at the other end.
> >
> > There are other useful examples which I can share if people are
> > interested.
>
> Agreed, this seems like a possible use case; but again, this is within
> a site, and the congestion points can be well-defined.  If it's not
> the first hop, then it's a predetermined point (or points) in the
> network.  Hardly something you absolutely need on-path signalling for.
>
> > > For that purpose, I'm not 100% sure if you would need a path-coupled
> > > signalling.  You'll certainly want path-coupled signalling for
> > > signalling with a much wider "span" (because it's the simplest way to
> > > do it from the host's perspective), but I'm arguing (as Dean was) that
> > > this isn't an interesting approach from the network operators'
> > > perspective.
> >
> > What about discovery of the furthest point. Do you not find that a
> > persuasive use case?
>
> Further point where you can use path-coupled signalling, you mean?
> Not really, as there seems to be something seriously broken if you
> need set up priorization except in well-defined points in the network.
> And to achieve that, you could use a "bandwidth broker": either it's
> able to set up the required bandwidth (it's in the same site, or at a
> site your site has a roaming agreement with), or it isn't and the
> approach is going to fail in any case, because the sites out in the
> Internet don't want outsiders to request bandwidth allocations.
>
> > > As for the alternatives:
> > >  1) for first-hop only, there's really little need for a router alert,
> > > any protocol would do, as you already know who your routers are :-)
> > >  2) for hops beyond the first-hop router, I'd consider setting up a
> > > single server which would be responsible for brokering the QoS
> > > capabilities, firewall holes, etc. You contact the server, and ask it
> > > to open a certain kind of hole, set up certain QoS between (source,
> > > destination), etc.  There are a number of options how you could
> > > discover this kind of system:
> > >     a) a DHCP option
> > >     b) a DNS lookup (e.g., SRV record based on your DNS search path)
> > >     c) asking the upstream router using protocol learned in 1).
> >
> > This assume edge tree topologies, which are common but hardly
> > ubiquitous.
>
> I don't think I assumed edge tree topologies.  Please elaborate.
>
> > > These kind of approaches essentially move the intelligence and
> > > processing to specific nodes who are better capable of handling such
> > > requests, having policy who can request what, removing the processing
> > > and cruft from the routers.  And the hosts have have much easier time
> > > figuring out whether requesting these capabilities is supported in the
> > > network, instead of spewing a considerable amount of in-band
> > > signalling attempts to the network.
> >
> > This is hardly a neutral characterization of the tradeoffs.
>
> (warning, could be flammatory)
>
> True enough, I had my operator hat on ;-).  My mind just boggled when
> I started to realize that some part of the IETF is still in denial on
> why RSVP didn't go through, and is now in the process of reinventing
> it .. wasting a lot of time and effort that could be much better spent
> on making an operationally more feasible system to provide these
> reservations in a well-defined, constrained points of the network.
>
> What I can't figure why this is happening.  I guess the IESG must have
> been asleep, or the most people just thought, "well.. let them waste
> their energy on that.. at least they don't bother us while they are
> bashing the heads in the wall.."
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf

cheers,
James

                               *******************
                Truth is not to be argued... it is to be presented


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf