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@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf