Slashdot Mirror
SBC Wants To Switch DSL Format To PPPoE
Mr. Haplo writes: "Looks like SBC's at it again. According to this story, SBC wants to change everyone's DSL connection to PPPoE. The article goes on to say that the California Public Utilities Commission and the ISP Association are filing complaints against SBC and PacBell over this. It doesn't mention anything about SDSL connections, however, so I don't know what they'll do, if anything, about them. They do say that business services would be left alone, though, so I assume this means just about any SDSL services (I hope!). Someone needs to take a baseball bat to SBC's executives."
How is this a bad thing for customers? I'm nowhere close to being an expert, but it seems to me that customers benefit from not being identifiable by a static IP. Doesn't it enhance privacy? According to the article, "PPPoE schemes make it easier for hackers to gain unauthorized access by seizing or guessing at dynamic addresses." Huh? Is it any harder to 'seize or guess' at static IP's? Once they know a static IP, isn't it easier to attack a specific target, or 'mark a favorite' victim? Again, I'm no expert, it's just seems obvious to me. I'm also not what you would call a fan of Bell, so it's not like I'm looking to justify this. But when "competing ISP's and (the ever-elusive) experts," try to inform me, I get a little skeptical. Not to mention that InternetWeek's about page doesn't exactly strike me as consumer-oriented. Judging by the other comments, it seems to me like a benefit to customers is being weighed against inconvenience to business. And while I doubt Bell's motives are so pristine, forgive me for not being sympathetic.
There is a saying among old telecom people: "If the telephone company were to sell sushi, they would advertise it as 'Cold, Dead Fish.'"
SBC has once again proven this cold adage with its silence about the switchover from Virtual Circuit/Virtual Path routing of DSL to PPP Aggregation. Nothing on the SBC web site. Nothing from the "customer service" people. Nothing from the ISP, as they are in the dark as much as the customers. As the first northern Nevada customer of DSL (Nevada Bell) I'm facing this changeover and am not happy about it.
The bottom line is that something has to change. The fact is, DSL provisioning is a crock bordering on kludge. To understand this assertion, let's take a look at the overall block diagram for DSL provision:
The DSLAMs connect to an Asynchronous Transfer Mode (ATM) network. In bridging mode (what I and many others in SBC-land who use an independent ISP have today) the data from the DSLAM port makes its way to the ISP using VC/VP channels that are nailed up. Once the circuit is nailed up, the number of CPU cycles required to switch 56-byte packets is very small indeed.
The independent ISP offering DSL connectivity needs a circuit into the ATM network, which for all practical purposes means getting at least a DS3 and an appropriate ATM switch/router. Assuming 40 megabits/s per DS3, you can handle 104 users of 384/128 DSL service, or 27 users of 1.5/384 service, at a time. With 10x oversubscription (low rate) that's 1000 and 270 users. With 50x oversubscription, that's 5200 users. Or is it?
ATM network was designed to handle relatively few channels at high speed. To this end, the address fields in ATM packets are short. With some horsing around, you can get about 1000 circuits per ATM link (and that DS3 counts as an ATM link). That means you cannot use a single channel for all customers. The actual ceiling is lower when you take into account routing problems, with a lower limit of about 250 channels.
The net result is that if you are an ISP you have to have multiple DS3 channels when your user base grows above a certain level. At $5K/month a pop, this limits the ability of the ISPs to control costs per port, which would tend to keep prices high. This is bad for the customer because it keeps prices high, it's bad for the ISP because it keeps costs high, and it's not all that swift for the ILEC...
Ever wonder why it takes so long to provision a bridging DSL circuit? One of the things I found out is that provisioning a single circuit requires an amazing amount of ATM network programming...in a process that is frankly broken. In the old days, BD (before DSL), the number of times the ATM network needed to be configured in a month could be counted on the fingers of one hand, and that hand could have taken a trip through a thresher or combine and still do the job. With the deployment of DSL, the fragility of the tools used to nail up circuits in the ATM network were exposed. There was a time when I could tell that Nevada Bell made another DSL sale: my DSL would stop working. The delay isn't in making the connections, it's finding open channels in every single link to use for the connection. Extensive bookkeeping.
So SBC decided to move to Point-to-Point Protocol Terminated Aggregation, replacing the VP/VC architecture that is currently in use.
So why didn't Ms. Semilof publish all this information? I wanted to know, and called her. She said that SBC wasn't forthcoming with information to give their side of the story. When I tried the usual press channels, I too got stonewalled. It took a call to a good buddy to get the information I need to generate the information showned above. Yep, once again SBC proves that the telephone companies don't know how to market.
Let's look at some of the hot-button items that other people have mentioned in this discussion.
Static IPs: The availability of a fixed IP address depends on how each particular ISP wants to handle things. If the ISP wishes to manage all aspects of authentication, Internet presence, and bandwidth control in the manner they do today, they can use L2TP tunneling over ATM to exchange traffic from user to ISP. The ISP's RADIUS server can serve up "sticky" IPs to emulate the static IP addresses many of us enjoy. It would be up to the customer to keep the PPPoE circuit alive if the customer is running servers at the CPE end of the circuit; not hard, but something on the list of things to do.
MTU problems: PPPoE has a nasty habit of forcing a smaller MSS than anyone expects, because of the packet overhead of PPPoE itself. This has been dealt with in many places, and the solutions are pretty well known.
Performance hits: Well, yes. Adding layers of protocol will cause slowdowns. There is another [active] router in the way, too. Expect ping times to go up. (Sorry, gamers, if you really want good ping time you will be forced to a T1 type solution.) Throughput will be affected, too, although I don't know by how much.
ISP concerns: In the current situation, it's a real hassle to switch from one ISP to another. When I switched away from NBI to my current provider, the process took 7 days, 1 day of which my DSL was completely out. With the changeover to PPPoE, though, the only thing a customer has to do is change the PPPoE login sequence. The ISP never knows the customer is going away until s/he calls to close out the bill. I discount the cost problems associated with the switchover, although most ISPs are running such razor-thin margins that the couple of thousands of dollars this will cost them in new equipment will hurt, hurt, hurt. (The gain is that the ISP can increase the oversubscription rate and thus lower running costs, which makes that couple of thousand in equipment plus technician time an investment.) Another concern is the lost of VPN business, as PPPoE lets an enterprise participate so that telecommuters can log in directlywith the company during the day to work (bypassing the ISP), then log into the ISP at night to play.
From Verizon.
And it doesn't suck.
Millions of /.'ers gasp in astonishment.
I mean, I use a Linksys router that has the PPPoE firmware installed. This means that i have a static IP anyway as the router uses a Keepalive and is never turned off. This is almost no different from DHCP. If your machine is not connected when the address is renewed, you don't get that IP address. Period.
Static IP's I can understand, but the people who really need them can pay for them. *GASP!* Heresy!
Yes, low-cost high bandwidth is what we want, but not necessarily what we will get. Yet. As I'm fond of saying, Joe Q. User who buys Compaqs at Best Buy with WinME installed will think nothing of a PPPoE connection. And that's if he even goes beyond his 53.3K POTS connection.
While my system at home is a cable modem; my coworkers are having lots of problems with our corporate IPSec software if they run PPPoE.
That sounds like you bought crappy software and didn't check it out before you bought it. IPSec works just fine over PPP and PPPoE. In fact, it shouldn't even be messing with the PPP frames, just like it shouldn't be messing with the Ethernet frames. It shouldn't know or care what it is being run over. It playes with TCP frames, nothing else. If it was then it is a problem with the IPSec software, not PPPoE. PPPoX, Ethernet, ATM, etc, should all work at the lowest level, the IPSec should be in the lowest level of the IP stack. Don't blame PPPoE because your software sucks.
By and large I've used PPPoE for about a year now, and have never had a problem doing anything "creative". Maybe you'd just prefer a regualar old, ethernet connection, which is your choice. But no one ever gets what the choose. The system provides you with a routable IP address and a place for the IP Packets to flow through, which is all you really needed to talk to the rest of the world. If you need anything else to be creative, then something is drasticly wrong.
This is nothing compared to what they've done before. I used to work for a regional ISP that resold SWB's DSL. They gave us access to their prequalification tools, which we used to assess availability of services when someone enquired
It would give results as green, orange or red. Most often it came up red.
We didn't think anything of this until we started getting phone calls. It turned out almost everyone who came up red would get a postcard from SWB within two weeks telling them about this wonderful new DSL service that had just become available in their area.
We refused to sell SWB DSL after that point on principle.