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.
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.
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.
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.
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.
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.
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.
Tony
What I-D's are you encountering that depend on RSVP?
--Dean
On Tue, 10 Aug 2004, Fleischman, Eric wrote:
I am aware of some use of RSVP in labs but I am not aware of any use of
RSVP in production networks (i.e., real life networks people connect to
the Internet with). Simultaneously, I am encountering I-Ds and other
work planning to use RSVP. This possible disconnect concerns me.
Therefore, I would appreciate being educated by anybody using RSVP in
production settings. Would you please let me know how many devices, what
applications, and how successful these deployments (if any) are? Thank
you.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf