On Fri, 13 Aug 2004, Tony Hain wrote:
Dean Anderson wrote:
RSVP is a idea that doesn't cut the mustard in the real world. There are
several show-stopper problems with RSVP.
Propagating clueless FUD does not result in progress.
That is true. Lets try to keep the FUD to a minimum.
1) somewhat like multicast, anyone using RSVP is vulnerable to others
mis-using or mis-configuring RSVP. ISPs several AS's away can really screw
up things for other ISPs. Because of this, it is unwise to deploy it
because it requires too much trust in other ISPs.
Inter-provider trust is something the Internet has to deal with. The
self-proclaimed gods of the ISP world bluster about how much smarter they
are than the Bell-heads, but even the lowly Bell-heads figured this one out.
Literally true. Most choose not to trust providers they don't know
anything about and have no direct connectivity with. Some choose not to
trust those they have direct connectivity with. Some choose to run
alternate internal networks and not trust the other internal networks.
But unrealistic amounts of trust is something you'd have to to deploy RSVP
in the general internet. It has nothing to do with bluster or competition
with Bell-heads.
That relegates RSVP to the enterprise Lan, where it usually isn't needed.
Remember, RSVP is only useful if you have a congestion problem and need to
choose which packets to discard.
RSVP is a signaling protocol. The policy installed in the routers with
congested links is the one deciding what to discard, and it has the
opportunity to take hints from that signaling if it chooses.
Despite rumors to the contrary, most complex enterprise networks include
non-LAN links, and even in the all-LAN case there are speed mismatches
between old and new segments.
Complex, as in fortune 1000. fortune 5000? (no such list, I think, but you
get the idea). There aren't actually that many organizations that have
more than one office.
If you have no congestion problem, then
you have no need of RSVP.
Signaling is useful for more than QoS, though it is not clear that RSVP as
currently defined is useful for signaling non-QoS related policy.
Literally true. But its not clear that RSVP is useful for anything,
outside of some very limited situations.
However, having a congestion problem also opens
the question of the nature of the congestion and what is the best way to
deal that problem. I was involved in a study done by Genuity and Cisco in
which the congestion problem was found to most often involve the tail
circuit--the link between the customer and the ISP. The best solution for
this problem was found to be low latency queuing, not RSVP.
As you say it depends on the nature of the congestion, but also the nature
of the application in the face of congestion. Generalizing all complex
topologies to a congested uplink just leads to protocol decisions that are
useless in the real world.
I'm not generalizing topologies. I'm generalizing the type of problems
that need to be solved. We have a whole lot of situations with tail
circuit congestion and comparatively few problems with large enterprise
congestion.
2) Unlike multicast, every hop end-to-end must use RSVP for it to be
useful. An RSVP tunnel is useless.
This is the type of BS that keeps useful tools out of the hands of those
that need them, but don't have enough time to figure out the reality. The
only points that need to pay attention to signaling are those where
congestive loss is likely to occur. Even then, a smart implementation might
only pay attention once a threshold has been crossed indicating that queues
are building.
3) RSVP doesn't detect certain kinds of problems that are important. For
example, a mid-span failure is not visible to RSVP.
WTFO! RSVP is a periodic signal, so it does detect and respond to mid-span
events.
Yes. Sooner or later RSVP will notice a link is down. But so will BGP and
OSPF. One wants this to happen within milliseconds in a QOS solution. An
old saying somes to mind: "Same day service in a millisecond world".
While RSVP is important research, it is not a widely deployable
technology.
The reason the Internet has been successful is that each administrative
domain gets to decide which technologies are deployable. Your decision that
RSVP is not deployable does not automatically restrict if from wide
deployment.
In answer to Eric's original question, the FUD being spread through
responses like Dean's have squelched what little RSVP had been deployed
several years ago. That does not remove the need for a signaling protocol,
as many WGs find they need to define new ones or variants. The bottom line
is that the lack of a trust model makes operators suspicious of any external
signal.
I didn't say that a signaling protocol wasn't needed. I said that RSVP
doesn't cut the mustard for the needed protocol.
--Dean
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf