Re: Engineers fixing networks & IntServ <NOT FOR THE LIST>

[David Farber <dave () farber net>]

________________________________________
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