The two sides of (PPPoE) DSL service

March 19, 2011

(A quick disclaimer: this is how it works in Toronto. I think it's how it works pretty much anywhere where you have a choice of DSL providers, but I'm not sure.)

There are two parts of your DSL service: providing the basic DSL signal tone, what lights up the '(A)DSL' light on your DSL modem, and your actual PPPoE-based 'DSL ISP service' that connects you to the Internet through your ISP. What a lot of people don't realize is that these parts are not tied together except in a business sense (you can't normally buy one without the other). There is nothing that says 'this DSL ISP credential can only be used on this line' or 'this line will only connect to this ISP'; instead it is more like plugging into a cloud and then bringing up a VPN to your ISP.

(This is basically why (and how) the 'test@test' special testing DSL username that I mentioned yesterday works. It's just another available DSL 'ISP' and credentials.)

This opens up a number of tricks. The most useful one is that you can bring up your regular DSL connection on any line that has DSL signal (either because your line broke but you have access to some other one, or just because you're at someone else's place). You can also connect to multiple DSL services at once on the same line, from either the same computer or (I think) different ones.

This also means that it's possible to test known working elements of DSL service independently. For instance, assume that you are trying to help a friend get their DSL connection working on their computer, and you already have your own DSL connection. You can troubleshoot their computer, their DSL ISP credentials, and their DSL line separately; you should be able to bring up their connection on your computer and your line, their computer ought to be able to bring up their connection on your line, and your computer ought to be able to bring up your connection on their line. This can be very useful and reassuring if you seem to be fighting multiple issues at once.

The most interesting trick is that it is theoretically possible to have a 'bare' DSL ISP, one that simply gives you DSL PPPoE credentials and leaves it up to you to get DSL signal tone somehow. At one point the University of Toronto effectively was such a creature (through a special agreement with Bell); if you already had a DSL connection, you could authenticate with your UofT identifier and you would wind up being directly connected on the UofT network. Among other things, this generally resulted in better performance when you were talking to UofT machines since you didn't have to go through the Internet to do so (and at the time the Internet was slower than it is today).

(As far as I know, Bell will not sell you bare DSL signal tone at all and I don't think any ISP here offers bare DSL credentials as a normal service. It's possible that there are contractual restrictions between Bell and the DSL ISPs that prevent them from doing so, although I doubt there are any technical restrictions that would prevent a very, very friendly ISP from setting this up as a temporary favour. Note that 'bare DSL signal tone' here is different from naked DSL.)

As a side note, I don't think that this was a conscious design goal of the local DSL environment so much as just the easiest way to implement a system where the telco gives multiple ISPs access to the basic DSL infrastructure. Restricting what line can talk to what ISP (possibly with what credentials) is simply more work than designing and running a cloud-like architecture that's a free for all, and there's certainly less to go wrong (at the telco's level, at least).

Written on 19 March 2011.
« How to configure a (PPPoE) DSL connection on a normal Fedora 14 Gnome desktop
The devil's advocate argument against paying attention to web standards »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Mar 19 02:31:26 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.