Interesting People mailing list archives
Re: Engineers fixing networks & IntServ <NOT FOR THE LIST>
From: David Farber <dave () farber net>
Date: Wed, 30 Jul 2008 03:22:29 -0700
________________________________________ From: Michael O'Dell [mo () ccr org] Sent: Tuesday, July 29, 2008 8:33 PM To: Craig Partridge Cc: David Farber Subject: Re: Engineers fixing networks & IntServ <NOT FOR THE LIST> Craig Partridge wrote:
Mike O'Dell observed:that would have been "IntServe" the failed Integrated Services model promulgated in the IETF half a decade later which was never viable at at the scale of the Global "Big-I" Internet.As the former co-chair of the IETF IntServ Working Group I think the failure had more important lessons than Mike suggests. I may be wrong, but my sense was that IntServ failed less due to scalability issues (which existed, but I think were solvable) than to the interesting paradox that we designed precisely what the majority of ISPs, user groups and vendors said they wanted -- namely the ability to reserve guaranteed bandwidth with sturdy delay bounds -- and discovered no one wanted the service badly enough that they'd pay what it cost to offer it. It was more cost-effective to buy more bandwidth. Even more important, from my perspective, was that the IntServ work was firmly grounded in some excellent theoretical work which strongly suggests that something like the IntServ solution is about as good as you can get. Lots of fascinating papers ground down into three sentences: Most (all?) of the packet handling schemes that give delay & bandwidth guarantees have been shown to be variants of what could be called a Demers-Keshav-Shenker-Parekh-Guerin system (as a field, we lack a name for it). And we can map between bitwise and packetwise schemes. So bits/packets, doesn't matter, you want guarantees, you're stuck in a result space people don't like. And, last I checked, all proposals for performance guarantees in the past 15 years (ATM, IntServ, etc...) have been, at their core, the same ideas. Which is why, when you read things about improving Internet service, you see lots of discussions of "priorities" and "improving" service without discussions of guarantees. We've been down the guarantees road and don't like the result. Craig ************************* Chief Scientist, BBN Technologies Outreach Director, GENI Project Office E-mail: craig () aland bbn com or craig () bbn com Phone: +1 517 324 3425
Hey Craig! Long time no bits! My intent was not to open old wounds, rather indicate the ghostly staying power of things which have been left beside the road. As an aside, I dunno which large ISPs wanted IntServ, but that's not my point, either. As far as I could tell, IntServ was an academic/geopolitical countermeasure for resisting the advance of ATM, or at least it was certainly positioned that way in many quarters. With IntServ, who needs ATM? (I realize a lot of good work was done along the way and some of it got painted in ways the authors did not intend.) The curiosity, however, is that given ATM's sophisticated QoS machinery that came in more flavors than Baskin-Robins ice cream, *nobody* actually used it except in some carefully controlled situations on private ATM networks. (several classified videoconference networks come to mind) the public ATM service networks, which there were but a very few, never sold a connection that really used all the QoS stuff because nobody knew how to turn the dials on it. again, excepting support for video-conferencing because that runs constant-bit-rate codecs and it says "H1 channel" - 384Kbps in the manual. (The fact the carriers were not clueful enough to "provision" the service in any but the most rudimentary forms also had something to do with it.) The reality is that i have never found an application, other than real-time media delivery, for which the answer to a question is denominated in "guaranteed bits per second". (other than overt pedantry) When an Oracle app isn't working for network reasons, the answer is not of the form "If it only had another 15Kbps *guaranteed* it would be fine!" Yes, the answer might be "move from a T1 to a T3" but that's not about fine-grained bandwidth guarantees of the form promised by ATM and IntServ. (it's usually about latency, not bandwidth) No, the people I talked to who claimed to need guaranteed bandwidth and likewise claimed to have cash-money in hand to get it had visions of making the Internet into a poor version of Cable TV (that seems redundant somehow, but no matter). But my main point was not to cast aspersions on IntServ, rather to point out the power of Internet Myth to impact policy. cheers, -mo ------------------------------------------- Archives: https://www.listbox.com/member/archive/247/=now RSS Feed: https://www.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com
Current thread:
- Re: Engineers fixing networks & IntServ <NOT FOR THE LIST> David Farber (Jul 30)
- <Possible follow-ups>
- Re: Engineers fixing networks & IntServ <NOT FOR THE LIST> David Farber (Jul 30)