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