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."
Whoever reported this story didn't read it all the way. SBC provides the DSL telephone lines. They also offer an ISP service on the lines. They also allow other ISP's to use lease their lines to provide internet service from that third party company. The article says that they are considering changing the policy to make it so all the third party providers can only use PPPoE. The ISP part of SBC will still offer Static and PPPoE service. Yeesh.
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.
And getting a router with a PPPoE client in firmware isn't a total solution, since in my experience SWBell drops my connection every day or so and I have to go into my router's config page and reconnect manually.
PPPoE will reduce your data transfer rates because you have to use some of your bandwidth for the PPP header information. Every time you encapsulate your transmissions in a new protocol, you loose some performance, because you must process the protocol headers, and the headers for each protocol eat up bandwidth.
I don't really understand what the outrage is about. Sure, PPPoE is a hack, you lose 1% of your expensive bandwidth to useless control information, and dialing up on a connection advertised as "always on" is pretty damn lame. In practical terms, however, it's not the monster some readers here make it out to be. I've had a Verizon PPPoE line for over a year now, with alternately a BSD or an NT box happily keeping a 24/7, always on, no user intervention required connection used by a number of other machines on the home LAN. No "router firmware" someone mentioned, no "manually dialing up", no "waiting for the browser to open the first page", no problems.
:)
I think the real issue here is simply the hurt pride that comes with being forced by a monopolistic provider to use an overtly dumbed-down consumer solution and knowing that it could have been - and was, for a short time - better. I'd, however, take a 1.5M PPP link over a 53k one any day and not be too bitter about it considering the improved price/performance ratio.
I use an SBC DSL line with a third-party ISP, and I know the people who run this ISP, so I actually know what I'm talking about. The reason SBC wants to force everyone to use PPPoE is simple: they want to take away all the advantages that third party ISPs can give to customers.
My ISP doesn't use PPPoE, and they give everyone a static IP address. These two features, along with the fact that this ISP has several upstream providers (unlike SBC, which has exactly one) and is run by competent and knowledgeable staff, is what makes it an attractive alternative to the local SBC ISP. If you go with SBC's ISP, you have to settle for PPPoE regardless, and they charge an additional 40 bucks a month for a static IP.
With the new ISP contracts SBC is forcing everyone to use, third party ISPs won't be allowed to give out static IP's. Yes, it's technically feasible to do so, but SBC won't let them. So there will be fewer reasons for anyone to go with a third party ISP.
It's a great model: rather than adding features to your own product, just take away features from your competitor's.
Because when using PPPoE, they can force all sorts of nonsense on you:
1) Changing IPs. No one wants this crap. If you plan to run any kind of server at all over your (capped at a crappy 128kbps) connection then you need a static IP. Hell, if you want to VNC into your box you need a static IP. Yes, those dynamic dns services can help but they are still not as simple and easy as a plain static IP.
2) Needs PPPoE support on your hardware. If you plan to share your connection you are out of luck if the router doesn't have PPPoE built in. While a lot of the newer ones do, many older cable/dsl home routers do not. That means you need to pick a box and run every other computer through it with some lame crap like Internet Connection Sharing.
3) Need PPPoE support in software. We've had earlier stories on Slashdot about PPPoE and SBC making funny little changes that made it harder for non Windows/Mac users. But even if it works right now, what's to say it will always work that way if they don't officially come right out and say they support alterate OS's?
4) Waiting to connect...very very damn irritating when you just want to read something and you have to wait for PPPoE to sign in. Admittedly faster but still why should we have to? SBC owns enough IPs to last forever. We also go instantly back to those happy days of running programs to fake internet activity to keep from getting kicked offline for being idle.
I signed up with PacBell and a one-year contract and got a static IP. Three months later I was unable to connect and the tech support seemed incredulous that I wasn't on PPPoE. No amount of effort and energy would get me put back on static because I foolishly did not get it in writing before I signed up (at the time, I had no reason to believe PacBell had any interest in forcing current customers to PPPoE even though I knew a couple months after I signed up that new customers were PPPoE only). I ended up having nothing but trouble because of various PPPoE related problems and finally got out of my contract by telling them I was moving to the Bay Area and the local PacBell didn't have any open ports to provide me with DSL service.
I'm still stuck with an Wirespeed DSL modem. I should probably put it on eBay or something.
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
Just to clarify, it seems that pppoe only increases the header by 8B... the max MTU is 1492 instead of 1500.
t ml
http://www.cisco.com/warp/public/794/router_mtu.h
some karma... and kinda lukewarm about it.
http://www.google.com/search?q=PPPoE+mtu
I'm surprised at how clueless some comments are here on slashdot. Obviously, a lot of people complaining about PPPoE have never used it. I've been using PPPoE for over a year now, on a 1mbit DSL line provided by Sympatico (canadian ISP).
First, PPPoE allows uses of multiple IP addresses over a single modem. Kinda like what you get with a PPtP VPN. Not hard to do either. Plug the DSL modem in a switch/hub. Plug computers in said hub. Have each comp make a PPPoE connection. Each gets a separate ip.
As for the ip not being static... Well if you have a router that has PPPoE support in the firmware, and always leave it plugged, you indeed get a pretty static ip. I've been connected for months in a row and my ip never changed.
Some other people were complaining about... overhead! Now get serious. The overhead is so near zero that it's not in ANY way perceptible. Unless maybe you have a Gigabyte connection. My 1Mbit DSL always download at around 126k/s, which is the line's max throughput. Ok, in theory it's 128k/s, but I doubt many people would notice a 1k/s difference. And I'm not even sure it's caused by the PPPoE protocol, it might just be the line.
The only problem I've had with PPPoE is that it doesn't work for software that tries to communicate directly with your ethernet port. nmap is an example of this. It's extremely rare occurance though.
PPPoE isn't a bad solution for the user, really. Just the simplicity for having multiple computers with their own ip over the DSL is worth it for most users with more than one comp. And if the ISP is reliable, you'll keep your ip for months. I think most people are complaining just because it makes them feel nice to complain. Well... this is slashdot after all.
Religion is the best example of mass psychosis
PPPoE is not inefficient, and in fact it is an Internet standard. The MTU has nothing to do with anything.
If PPPoE encapsulated the data packet, then it is inefficient and the MTU has everything to with everything.
Anytime you encapsulate, you reduce the MTU of your packet by roughly 25Bytes. Applications that attempt to use the full ethernet MTU then have to fragment their data. This requires CPU cycles and bandwidth. And if you want to create a tunnel through that... you reduce the MTU again.
I do this stuff for a living. I suggest you learn about encapsulation and tunnelling before you spout off. And next time, post under a real ID, not an anonymous coward.
Wanker....
some karma... and kinda lukewarm about it.
The Linksys router occupies approximately 6"x8"x1". It's not a big piece of equipment. I've seen them as low as $69.99 online.
It's a wonderful fix to the PPPoE situation. It also gives you a firewall, a 4 port 10/100 switch, and a proxy server.