<<< Date Index >>>     <<< Thread Index >>>

[IP] WORTH READING more on worth reading "A Piece of the Action"





Begin forwarded message:

From: Louis Mamakos <louie@xxxxxxxxxxxx>
Date: January 22, 2006 8:58:21 PM EST
To: dave@xxxxxxxxxx
Subject: Re: [IP] more on worth reading "A Piece of the Action"

Dave,

As one of the perpetrator of PPPoE, I can say that "I was there" when the protocol was conceived, and I can relate the reasons why. What has happened subsequently, I take no credit/blame for.

At the time, I was at UUNET (er, MFS, not thats not right, WorldCom). Well anyway, we though of ourselves as "UUNET" at the time before the dark times came, but that's another story. I was working on a design for a DSL product offering we wanted to roll out.

At the time, DSL for Internet was very much a new thing. Many vendors where out there and many of them were trying to "add value" by making their DSLAM and associated CPE device little baby brain- damaged routers, and "IP aware". They mostly all did a pretty poor job of it and it created more problems than it solved. In particular, having DSLAM be an IP router means that your customers all have related IP addresses, or at least routing policy and this makes competitive equal access to the underlying DSL infrastructure impossible.

Every wonder why there's little to no competition in choosing what ISP you want to use on your cable plant? This is why -- it's because the CATV IP service is tightly bound with the transport over the medium. We didn't want that to happen again, and we really wanted the DSL plant to know NOTHING about IP at all. Incidentally, this is what will allow some DSL ISPs to offer IPv6 to their customers sooner; the DSL plant doesn't even know.

Anyway, so we were casting about trying to figure out how to make this work. Of the brain-damaged hardware we knew was deployed, and there was a lot of it, pretty much all of it could be lobotomized and just operate as in a dumb, simple, Ethernet bridge mode. That met our need for L3 protocol insensitivity and enabled competitive access.

We wanted to enable competitive and wholesale opportunities for ISP access here as well; UUNET had been tremendously successful building a wholesale V.90 dial-up access network, and we wanted to enable that same capability here. The key to making this work was enable the ability to delegate the authentication for the customer wanting access; with PPP we did this at UUNET by inventing the RADIUS proxy and forwarding the authentication requests to our third-party wholesale customers by a simple syntactic examination of the principle name being authenticated (e.g., UU/louie or louie@xxxxxx or louie@xxxxxxxx We never did UU!louie which would have been a great inside joke!)

So, you could have competitive access at:

- the wire loop (being your own DSLAM)
- the logical connection to the CPE device (use their DSLAM, buy some ATM or other backhaul) - the customer (use someone else's router/session termination, bring your own email, NNTP, news, etc.)

We then just looked for the obvious way of running PPP sessions over
Ethernet; figuring that PPP ran over every other damn thing. But remarkably, there was no such thing, so we did an 80% solution in 20% of the time and it appears to have addressed most of the requirements. Ideally, we would have used something simple like L2TP over Ethernet, but that didn't exist either, and it would have been 18 months getting through the working groups. I expected PPPoE to be a proof-of-concept, with the L2TP crowd pickup up from there, but it never happened.

Further, because of the way that PPPoE worked, you could share the DSL span with multiple end-systems in the home, each connecting to a different PPPoE session aggregator because of the discovery process. We wanted to enable an AOL-like residential ISP on one PC and a very different connection (work-at-home or something) on another PC, each with their own PPPoE session. You could even connect multiple DSL CPE devices, each with their OWN DSL span back to different PPPoE session aggregators and have multiple sessions operable at the same time using a single LAN at the customer premise. Of course, none of this cool flexibility ever got used. Oh well.

Skip forward 5 or 6 years, and what did we learn:

- our believe that Path MTU discovery would be workable in the face of the 1492 byte MTU failed due to zealous filtering of ICMP traffic

- not all of the competitive opportunities to hook into the DSL infrastructure were taken advantage of. There are lots of reasons for this, almost none of them technical

Control or choice? I guess it is a matter of perspective. When we set out to do this, it was to enable options that were not (and are still not) available on Cable TV-based Internet services. And those limitations probably were not by accident, if I had to guess.

Today, I believe that cable operators have better control over bandwidth, especially upstream bandwidth. If you think about the MAC layer used on a cable TV plant for broadband data, the upstream channel cannot be contention based; the CPE device is assigned timeslots and thus a fixed upper bound on the bandwidth available. Certainly there are session termination devices that can apply traffic policers and shapers and other policies to traffic that would apply equally to both cable and DSL. Of course, it's been a few years since I've crawled around in that world of building networks so the details may have changed.

Louis Mamakos
UUNET alumni



David Farber wrote:
Begin forwarded message:
From: Jeff Schult <jss@xxxxxxxx>
Date: January 17, 2006 3:22:07 PM EST
To: dave@xxxxxxxxxx
Subject: Re: [IP] more on worth reading "A Piece of the Action" (was: Charging "content providers" ...)
Reply-To: Jeff Schult <jss@xxxxxxxx>
Dear Dave,
My own recollection from having worked at a telco or two on the Internet side of things is that they had their eye on multiple tiers of service almost from the moment that DSL became a potential product -- and that this was a factor in the telcos all (curiously?) opting to use and specify PPPoE rather than the simpler cableco DHCP distribution. Someone closer to the fray than I am now could perhaps shed more light on this, but I suspect that the telcos have more control over the deliver of metered bandwidth to individual customers than do cablecos?
-jeff schult
-------------------------------------
You are subscribed as louie@xxxxxxxxxxxx
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip
Archives at: http://www.interesting-people.org/archives/interesting- people/


-------------------------------------
You are subscribed as roessler@xxxxxxxxxxxxxxxxxx
To manage your subscription, go to
 http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/