Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
ADSL Done Wrong: Technological Impediments to Consumer Broadband

By Mike Hunt in Internet
Tue Jul 16, 2002 at 09:38:33 AM EST
Tags: Internet (all tags)
Internet

In places where DSL-like services have taken off, they have almost universally suffered at the hands of poor implementations and telecommunications oligopolies.

By drawing an analogy with standard dialup services, I'd like to present an alternative implementation which would make it suck less.


ADSL is almost universally implemented as an ATM data-link layer running on top of a high-frequency copper carrier physical layer.  A second data layer, usually Ethernet (sometimes with PPPoE) but sometimes PPPoA (PPP over ATM) is implemented on top of this.

In Australia, and presumably elsewhere, the incumbent telco (Telstra, in Australia's case) has a monopoly on most of the POTS lines running into people's houses.  This, naturally, means that the ADSL signalling equipment at the exchange is under their control.  So what happens if you want to sign up with a competing service?

The 'traditional' way to do it is for Telstra to provision different VPI/VCI pairs (more on these in a minute or two) which get switched via ATM back to ATM equipment at the competitor's office.  The ATM is then thrown out, and Ethernet, PPPoE or PPPoA can be run over the VC between ISP and Customer.  This model sucks.

Lately, Telstra has been trying to flog an even less effective 'pro-competition' model, L2TP.  In this scenario, telstra terminates the PPPo[EA] session for you and hands the PPP frames back to you through their ATM network to your L2TP server, which handles the PPP encapsulation, radius, etcetera.  This model also sucks.

The third alternative which we haven't really seen in Aus, but I'm informed is quite prevalent in other countries, especially the 'ol US of A, is where competing carriers co-locate DSL equipment at the incumbent's exchanges, and individual copper pairs belonging to subscribers are patched into the correct carrier's DSLAM.  There have reportedly been problems involving the Bells doing sneaky, underhanded and just downright mean things to their competitors, such as 'accidentally' un-patching several hundred pairs at one of the distribution frames between DSLAM and customer.

In order to understand the model I propose below, you'll need to understand a little bit about how ATM works, and why it works.  If you know these things already, feel free to skip the next couple paragraphs.

ATM is a cell-routed data link protocol which has similarities with ISDN, Frame Relay, and, surprisingly TCP/IP.  When an ATM 'end device' wants to send data to another ATM end device, it fragments data-link frames into 48 byte cells, and prepends a 5 byte header which includes a cell checksum, and the destination Virtual Path Identifier and Virtual Circuit Identifier.  The intermediate switches have switching tables which contain instructions to the effect of 'cell with VPI/VCI x/y and input interface z, gets output with VPI/VCI a/b and output interface c'.

ATM also supports quality of service, by specifying certain types of Virtual Circuit in part of the specification known as 'ATM Adapatation Layers.'  These, however, are unimportant here; all that's required is to realise that we're talking about Variable Bitrate Cell-Switched data, which meets the criteria of AAL5.

Now, the cell switching tables can be built in one of two ways.  Either statically, by hand (on each intermediate switch - this becomes something of a nightmare eventually); or by using ATM signalling to dynamically build virtual circuits between two end devices connected to the same ATM network.  In order for ATM switches to know which destination device a given source device is talking about, it needs some concept of addressing.

Enter the NSAP address.  This is usually 20 bytes long, and has the format (prefix).(station address).(selector byte).  The selector byte is almost always zero and is used to differentiate different ATM applications running on the same device.  We can safely ignore it.  The prefix is specified by the ATM switch the device is connected to, and has a variable length.  The E.161 standard specifies a 13-byte prefix length.  The station address is much like a LAN station address and is six bytes in length.

Now, after an end station registers with its directly connected switch, it sends a packet identifying its station address to the switch over well known VPI/VCI pair 0/16, which is referred to as ILMI (Integrated/Interim Local Management Interface.)  The switch then advises the end device of its prefix, and all is well.

Amongst themselves, the switches run a link-state routing protocol to advise each other of which prefixes they can reach.  Eventually the network converges.

Eventually, an end device wants to set up a virtual circuit to another end device, so it announces its intention to the switch via the ILMI mechanism.  Based on its routing table, the switch sends a similar request to its next-hop switch for the requested prefix, and eventually the connection request reaches the other end station.  After acknowledgements are sent back in the other direction, the switch announces the VPI/VCI pair for the newly-built circuit to the end device, and all is well.  Until the circuit is torn down (again via ILMI,) the VPI/VCI pair for the circuit functions identically to a hard-coded PVC.

Now, back to ADSL.  Since the entire network is built on ATM anyhow, why not simply connect your ADSL ISPs to the ATM network of whoever owns the physical copper, and let the end user initiate an ATM VC to their ISP of choice.  In this way, an NSAP address would function much like an 'ADSL Phone Number.'  You could either build the connection and then frame ethernet over it (much like ATM LANE, but without the complications,) or you could simply run PPPoA over the SVC.  This would fit in very nicely with the current 'dial up' model that most internet users are used to, albeit at higher speeds.

ADSL ISPs would need:

- ATM circuit into national carrier (as opposed to ISDN lines into national carrier for dialup modems)
- Slightly larger connection to the Internet (as opposed to what they have to support dialup).

As long as these two constraints are met, the whole thing would function flawlessly.

The only problem I can forsee with this method is that a user is likely to balk at a phone number which looks something like

47.0080c0.d00000.c0a0c0.470120.010044.3dc58e.00

but then, you could hide that from them with an Install CD.  The current VPI/VCI settings are hidden from them anyway.

How about it?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Also by Mike Hunt


Display: Sort:
ADSL Done Wrong: Technological Impediments to Consumer Broadband | 36 comments (33 topical, 3 editorial, 0 hidden)
Minor points (4.33 / 3) (#1)
by cafeman on Tue Jul 16, 2002 at 12:38:34 AM EST

In your third paragraph you say the second layer can be PPPoE or PPPoA.  Isn't PPPoA actually the second layer, and PPPoE a third layer on top of that?  I was under the impression that PPPoE was effectively PPPoEoA, with the Ethernet as an intermediate translation layer for compatability and ease of configuration.  In order to use PPPoE, you need a bridge (either software or hardware), where with PPPoA, you go straight into ATM.  So, PPPoA would be:

TCP/IP
PPP
ATM
Copper

While PPPoE would be:

TCP/IP
PPP
ETH0
ATM
Copper

Correct me if I'm wrong ...

Also, DSLAMS are very expensive, and forcing two infrastructure implementations is very expensive and economically inefficient.  It focuses competition in high value areas, but leads to a complete lack of focus in low value areas (such as the bush).  Witness mobile phone coverage in regional Australia for a good example.  Not disagreeing with your main suggestion, just commenting that the third point is also really bad (for reasons you didn't seem to have stated).

Apart from that, I'm not technically competent to comment on the rest.  Sounds good though - anything to get rid of that ridiculous $129 - $189 registration fee.

--------------------
"No Silicon heaven? But where would all the calculators go?"


Minor points with your minor points :) (5.00 / 1) (#2)
by Mike Hunt on Tue Jul 16, 2002 at 12:43:38 AM EST

1. You can either have

Straight ethernet over ATM

TCP/IP
Ethernet
ATM
Copper

or PPPoA

TCP/IP
PPPoA
ATM
Copper

or PPPoE

TCP/IP
PPPoE
Ethernet
ATM
Copper

The PPPoE isn't running over PPPoA.  It is, however, running over ATM.  If this is what you meant, I apologise.

with regard to the cost of the DSLAM, one of these guys is only needed to modulate the ADSL signal over the copper (it's essentially a physical layer device.)  All you would need at an ADSL ISP to replace the Modem Banks would be a PPPoA (or whatever) access concentrator with an ATM line coming out of it.  You can get a Cisco 7206 with ATM card off eBay for a few grand US. :)

MH.

I used to have a .sig, but the government told me it would cause cancer.
[ Parent ]

Clarifications (3.00 / 1) (#3)
by cafeman on Tue Jul 16, 2002 at 01:12:01 AM EST

That's pretty much what I meant ... the reference to PPPoEoA was more confusing than helpful.

Also, I was talking about the DSLAM in terms of rival ISPs / telcos deploying their own infrastructure in shared exchanges, as they apparently do in the US.  That's horribly inefficient, and in the long run leads to poor service in regional areas (since who really want to deploy a full scale, high-speed network in Dubbo?).  Plus, there's the opportunity cost of captial and operational expenses in deploying the network, money that could be spent with greater net benefit elsewhere.  Really, I'm supporting your suggestion - none of the three current approaches are as efficient as they could be.  One ATM device at each ISP would be much more efficient than 100 exchanges * 5 ISPs * 1 DSLAM each.

--------------------
"No Silicon heaven? But where would all the calculators go?"


[ Parent ]
You're right (3.00 / 1) (#4)
by Mike Hunt on Tue Jul 16, 2002 at 01:19:30 AM EST

The many-DSLAM approach is pretty dumb, but is far more maintainable than relying on somebody else to deliver the packets properly.

A friend of mine used to work in an independent xDSL wholesale company in St. Kilda road, Melbourne.  They sell both 2+2Mbit SDSL links over their own copper (not sure whose telco license they're using,) and resell Telstra ADSL.

Their SDSL customers are, by most measures, fairly happy.  Their ADSL customers have a high turnover rate, with many of them going to telstra.

Go figure.

MH.

I used to have a .sig, but the government told me it would cause cancer.
[ Parent ]

For those who don't know the acronyms / background (4.85 / 7) (#5)
by cafeman on Tue Jul 16, 2002 at 01:22:43 AM EST

DSL = Digital Subscriber Line
ATM = Asynchronous Transfer Mode
POTS = Plain Old Telephone Service
DSLAM = Digital Subscriber Line Access Multiplexer
NSAP = Network Service Access Point

For those who are interested in how DSL works, here's a really good link. Also, there are multiple types of DSL, as shown here, of which ADSL is current the most common.

Also, ATM is old school networking, created when a network meant a telecommunications network, not an IT network. I personally think it's a good thing to know where all this networking stuff came from (ie telecommunications). None of this easy gigabit stuff, ISDN, ATM, and Frame Relay all the way :)

Also, here's the obligatory link to Whirlpool, Australia's Broadband site (seeing as Telstra was mentioned in the article), and here's a previous K5 article on the state of broadband in Australia.



--------------------
"No Silicon heaven? But where would all the calculators go?"


That reminds me... (3.50 / 2) (#6)
by Mike Hunt on Tue Jul 16, 2002 at 02:27:38 AM EST

Funny that you should post an explanation of ATM...

not too long ago, when I and several others were young and stupid, one of my friends (who is now a developer, go figure,) heard about ATM and came to the conclusion that 'Mike.... All the ATMs in Melbourne have this REALLY REALLY FAST network connection!!!'.

Oh for a world with unambiguous acronyms.

MH.
I used to have a .sig, but the government told me it would cause cancer.
[ Parent ]

Acronyms (3.00 / 1) (#13)
by Beltza on Tue Jul 16, 2002 at 07:14:17 AM EST

Thanks for the explanation.
Fortunately I was able to find some explanations in the text:

ILMI = Integrated/Interim Local Management Interface
PPPoE = PPP over Ethernet
PPPoA = PPP over ATM

However, there are a lot more! Anybody out there to explain me also the following:

VPI
VCI
VC
L2TP
AAL5
PVC
LANE
SVC

The point is, all this jargon made the story unreadable for me. I wasnīt able to follow the story, and I still donīt know what the author is telling us.


Be alert!!!
The world needs more lerts...


[ Parent ]
Here are some more + explanations (5.00 / 2) (#16)
by cafeman on Tue Jul 16, 2002 at 07:33:01 AM EST

VPI = Virtual Path Identifier
VCI = Virtual Connection Identifier
VC = Virtual Circuit (I think)

Simple explanation is that these create a virtual circuit out of a switched network by specifying inputs and output ports (not quite right, but should be pretty close).  The numbers for each are used as identifiers for the data input and output, and can be different between the originating and destination terminators.

L2TP = Layer 2 Tunneling Protocol

Allows you to create a PPP tunnel over the Internet - think dial-up, except using the Internet rather than direct dialling.

AAL5 = A protocol, don't know what it stands for

My understanding is that it's is a protocol for packet formatting using ATM (another is AAL3/4).

PVC = Permanent Virtual Circuit
SVC = Switched Virtual Circuit

Software defined logical connection between two points on a packet network.  Permanent = permanent, Switched = temporary.

LANE = LAN Emulation

Lets existing connectionless network applications communicate over a connection oriented network (such as ATM).  Basically allows Ethernet to communicate over ATM.

Basically, the author is saying why not transform the existing DSL network from one where the incumbent telco has control over who connects to who into one where end-users can connect to whoever they want without the intervention of the incumbent, similar to the way telephones work now.  You put in your address / phone number, and you get the computer / person you want.  The way it works in Oz, the incumbent telco must connect you every time you change, similar to an operator.  Also, they charge money for the change in connection.

--------------------
"No Silicon heaven? But where would all the calculators go?"


[ Parent ]
A few more clarifications (4.33 / 3) (#26)
by bsg on Tue Jul 16, 2002 at 02:29:52 PM EST

Just to clarify a few more points...

AAL5 is one of several ATM Adaptation Layers. These layers exist for the express purpose of having an agreed upon protocol for data and voice. AAL3/4 was the first specification for data (remember AT&T's switched MultiMegabit service?). It was very unpopular with the data transport folks (Cisco, etc) because it is highly inefficient, so AAL5 was born.

There is also AAL1 and AAL2, but these are mainly concerned with voice and video.

An ATM switch handles these layers differently since the traffic has different characteristics. Data is bandwidth intensive, but can be delayed. Voice and video are delay sensitive, so they need priority over data.

LANE exists because ATM is a non-broadcast medium. Since you cannot broadcast on ATM, but you can on ethernet, LANE is a kludge to address this. Believe it or not, ethernet can be a connection-oriented medium if you want it to be. SNA makes use of this feature of Ethernet, but TCP/IP (and most other protocol suites) do not.

[ Parent ]

LLC2 (5.00 / 1) (#33)
by Mike Hunt on Tue Jul 16, 2002 at 07:32:56 PM EST

Yeah.  Ethernet _can_ do connection-oriented services, but by and large it's a huge hack over a medium which doesn't support it.

Basically, LLC2 (logical link control protocol two, methinks) is a way of specifying a TCP-like service over ethernet, and was used for IBM's SNA/APPN services (big, dumb, ugly, transaction-oriented mainframe hacks) as well as NetBIOS over L2 (aka NetBEUI.)

As I understand it, LLC2 were originally designed to be deployed over a deterministic medium, such as Source-Route-Bridged Broken Ring.  In its day, it was actually a good combination for rate-deterministic transaction-oriented services such as SNA (keep in mind that this more or less predates the commoditization (sp?) of routable protocols like IP(X)).  Deployed over Ethernet, you lose many of the advantages which make LLC2 desirable.

Interesting, the IETF developed (and Cisco 'embraced-and-extended') a standard called 'DLSw' (Data Link Switching) which was designed to tunnel LLC2 traffic over a routable backbone.  If you were running this LLC2 over a SourceRoute Bridged Layer 2 such as Broken Ring or FDDI, the RIF (routing information field) was terminated at the DLSw endpoints at both ends, removing the 7 (later 15) bridge limitation inherent in the protocol.  DLSw also provided 'local acknowledgement' to the LLC2 keepalive frames, preventing the LLC2 timeouts which had become almost commonplace when (especially in the case of legacy SNA, less with NetBIOS and APPN) running the protocol over a nondeterministic medium such as Ethernet.

Regarding LANE, yes - it's a kludge.  This doesn't mean, however (as some posters have indicated), that ATM is a complete dodo.  ATM is the one prevalent technology which has the capacity for carrying CBR data (such as E1 circuits), VBR non-realtime data (such as IP), and whatever the hell else you want to run over it.

MH.

I used to have a .sig, but the government told me it would cause cancer.
[ Parent ]

infrastructure (3.00 / 2) (#7)
by notAcoolNick on Tue Jul 16, 2002 at 03:15:38 AM EST

+1. Interesting proposal.

However I have to say that I am highly skeptical about whole field.

Existing phone lines are perfect for vice. But not for broad-band. It only works on paper. Twisted pair will never be better than coaxial cable. And besides all that phone equipment when it was put together was never ment to be used for high speed.

Personally I still use 56K modem. ISDN is too littel bang for a buck, *DSL for me is not an option because I am too far from central office and I'll never give any more money to cable companies. First off all they squized out competition (they are buy default now are the owners of the "last mile"). And their own infrastructure sucks too.

Hee Hee (3.33 / 3) (#19)
by wiredog on Tue Jul 16, 2002 at 08:19:07 AM EST

Existing phone lines are perfect for vice

Personally, I find them too slow for the online vice I prefer.

Can't sleep. The clowns will get me.
[ Parent ]

coax vs. t/p (3.50 / 2) (#22)
by miles b on Tue Jul 16, 2002 at 01:07:10 PM EST

Twisted pair will never be better than coaxial cable.

The last time I ran ethernet over a coaxial network, it was limited to 2Mbit on RG-58, whereas Cat-5e and Cat-6 can do 1Gbit on ethernet over twisted pair. That's 500x the speed of coax for a cable of almost the same diameter. The only advantage I can see to coax is that when you're pulling it, it doesn't kink as easily as twisted pair, but it can still happen. Sure coax may be less lossy than twisted pair but let's compare apples to apples here - cable of the same wire gague. 20 AWG coax is going to be miserably slow compared to Cat-5e. Besides, is there any ethernet other than 10-base2 that will run on coax?

[ Parent ]
Co-ax? (3.00 / 1) (#32)
by phliar on Tue Jul 16, 2002 at 06:29:46 PM EST

Twisted pair will never be better than coaxial cable.
Why do you say that?

UTP (unshielded twisted pair) has many advantages like cable thickness, cost, and ease of patching. What advantages does co-ax offer? Are line losses better with co-ax? (If replying, specify which co-ax.)

And besides all that phone equipment when it was put together was never ment to be used for high speed.
What do you mean by "all that phone equipment"? Which phone equipment? Crossbar switches, certainly. However, DSL only uses the actual local loop copper of the existing "phone infrastructure" -- at the CO it is connected directly to the DSLAMs, which connect to the data backbone.

(Aside: you need to work on your spelling.)


Faster, faster, until the thrill of...
[ Parent ]

Oz and the failing US Telcomm market (1.00 / 4) (#8)
by frankcrist on Tue Jul 16, 2002 at 04:31:52 AM EST

I dunno shit about Oz, but I will say that I'm really pissed about the whole WorldCom falling out.  These dumb-fucks (says the Makers' Manhattan) could've had a huge DSL/ADSL market in the U.S. via the UUNet market.  Instead, they cooked the books and short-sold us like suckers.  Now, instead of BroadBand, I have an IRA down 30%.  Thanks, dickheads.

--x--x--x--x--x--
Get your war on!
investment is gambling [n/t] (none / 0) (#36)
by 5pectre on Sun Sep 01, 2002 at 11:33:18 AM EST



"Let us kill the English, their concept of individual rights might undermine the power of our beloved tyrants!!" - Lisa Simpson [ -1.50 / -7.74]

[ Parent ]
Why ATM at all? (3.50 / 2) (#11)
by edison on Tue Jul 16, 2002 at 06:46:23 AM EST

Giving the user control over what to use his access line for is all nice and dandy. But why do we keep bringing ATM up?

I am aware of the fact that most DSL equipment (unfortunately) uses ATM as the underlying transport technology.. To me, this is bad. Anything you can do with ATM can be done with IP and MPLS, and this is where we should be heading.

The goals you set out can be accomplished even if we skip the ATM layer.

Sort-of ... (3.50 / 2) (#12)
by cafeman on Tue Jul 16, 2002 at 07:10:22 AM EST

You're right that anything done with ATM could be done with IP. But, it would involve discarding *much* existing telco infrastructure, which would be non-trivial in terms of cost. Reuse is the key word - why recreate when we have an existing network that does all that?

Besides, you're talking about re-inventing DSL, an established technology with existing services and products. You'd be hard pressed to build a business case out of that ...

In an ideal world, I'd have a fibre running into my house, offering OC3 level capacity via direct TCP/IP. In reality, the telcos have dropped billions and billions into their network, and they're a little shy about replacing elements as common as exchanges en masse.



--------------------
"No Silicon heaven? But where would all the calculators go?"


[ Parent ]
Skip ATM, go IP (4.00 / 2) (#15)
by edison on Tue Jul 16, 2002 at 07:22:47 AM EST

I would imagine that most "new entrants" would rather have a pure IP/MPLS network than several separate networks (such as an additional ATM network).

The fact that the older telcos all have ATM infrastructure in place is not a burden which should be placed on the end user's shoulders. Operating an ATM network is a bad strategic decision as far as I can tell.

Point is, the "market" (those large ISPs that have thousands of DSL ports, in reality) define what kind of equipment the vendors put out. The problem here is really that vendors are not making equipment which is practical for "sane" network operators, most cost-effective equipment is sane only to the old-school operators. This must change.

As far as I know most DSL chipsets can go around the ATM encapsulation and can be used to create a pure IP/MPLS link if needed. All that is needed is for vendors to realize that they must stop accommodating the players which will go bankrupt anyways, and start accommodating those who fully embrace the "better way of thinking" (IP all the way).

If not for pure technological "correctness", then at least to get rid of the stupid 20+% ATM overhead. After all, the access lines are the weakest loops in the network and any extra attainable bandwidth here should be put to good use, not wasted on ATM.

[ Parent ]

I disagree somewhat (3.00 / 1) (#17)
by cafeman on Tue Jul 16, 2002 at 07:39:31 AM EST

That works under the circumstances where you have multiple providers, each with their own network. We have one in Oz, Telstra. They own the infrastructure. As in the local loop, 99% of exchanges, and most of the major links in the country. We're too geographically diverse and have too small a population to allow new entrants to deploy their own networks and make a profit in the next 50 years (maybe even 100).

Basically, those large ISPs you're talking about are Telstra. And Telstra. And Telstra. The ISPs don't own the DSLAMs, or the Local Loop, or the exchanges, Telstra does. Everyone else has to use their equipment, hence the reason for the article. The US is has different problems, namely surrounding interconnectivity and efficient use of resources - it's duplicated its network beyond what is needed, simply because providers don't always use each other's existing infrastructure. It's highly economically inefficient.

You're right - DSL can do IP, but it's not financially possible here given the existing investment. You could probably do it in pockets it the US, but I think ATM will be around for quite a while. IP is the future, but telcos move slowly. They're not dot-coms, they're utilities with billions of investments.



--------------------
"No Silicon heaven? But where would all the calculators go?"


[ Parent ]
On .au and DSL (3.00 / 1) (#18)
by edison on Tue Jul 16, 2002 at 07:49:02 AM EST

Curious though, I live in Europe and do not have first-hand knowledge of the state of things in .au.

Why are there no other DSL(AM) operators? Is there no local loop unbundling legislation in your country?

And why do you assume that it would be impossible for a new entrant to make a profit, seeing as noone has been allowed to try (this is how I read your comment)?

[ Parent ]

Maybe misunderstood (4.00 / 1) (#31)
by cafeman on Tue Jul 16, 2002 at 05:19:57 PM EST

The DSLAM is the device that sits in the exchange and allows your DSL modem to talk to the internet. The local loop here is unbundled, but competitors have to use the incumbent's equipment, not deploy their own. Telstra owns the exchanges, and competitors aren't allowed into Telstra's exhcanges, hence they can't deploy their own DSLAMs. So, they haven to use Telstra's.

A new entrant could make a profit, but only in high value areas, just like in the US. We'd end up with (very small) pockets of Australia able to get very fast access. To put things in perspective, legally 'acceptable' outback data speeds are 9600bps. No shit. We're much better in the CBDs, but we don't have the population to allow a for a quick return on investment, given the costs involved. A company that wanted to hang around for 50+ years could probably make a profit, but not many are willing to do that.



--------------------
"No Silicon heaven? But where would all the calculators go?"


[ Parent ]
Broadband (4.20 / 5) (#20)
by TunkeyMicket on Tue Jul 16, 2002 at 08:43:02 AM EST

Broadband in the United States sucks ass unless you get lucky. I was lucky.

I live in the boonies of NC, my house surrounded by woods and few neighbors, quite the isolated area. We have cable via Time Warner, so when they started "beta" testing cable modems in our area, I jumped at the chance. In the beginning I could pull 6-7mbit down [almost a full megabyte] and push at a full 2mbit. These speeds were absolutely amazing. I could run game servers with ease, leave napster on 24/7, run an ftp/http suite, and still have enough bandwidth to download the files I wanted. My cable was this way for almost a year and a half. Then I went to college. At college I was on very very fast UIUC lines, and could pull the full megabyte and push nearly half a megabyte over the Internet. My Mecca was found. Arriving back at home I find that my cable does 20KBps max on the down and a lil over 10KBps on the up. WTF. Evidently Time Warner had stacked about 100 people on my local loop, when it used to be just me and my few neighbors. I guess the Road Runner auditors noticed that our small loop was using a large portion of the available bandwidth. They also stuck 2 more routers on the line, bringing my hop count to the nearest backbone to 4, from the previous 2. Internal pings between RR customers was between 10ms-15ms origionally. Now I would get 40ms-50ms pings to people in my neighborhood. I notice large amounts of packet loss at my gateway router. Ugh. The real slap in the face is RR's only way of fixing problems: Un-plug your modem, wait 90 seconds, plug it back in. Yeesh I could train a monkey to handle their tech support. They advertise speeds of 2mbit down and 512kbit up. 20KBps is much less than 2mbit, and 10KBps isn't quite 512kbit. I do understand that they don't have to provide me the advertised speed, just like Ford doesn't have to sell me a car which is like advertised. Oh wait, yes Ford does. So why the hell is RR any different? Hopefully a class-action lawsuit will force the fucks that messed up the broadband infrastructure to fix their mistakes.

To top it all off I can't get ISDN or DSL. Why? Because my neighborhood is so new they run fibre to the CO. Just peachy. What other alternatives does this leave me with? Satellite and Wireless. The first option is a negative, and the second option is pretty fookin expensive. I could also buy a burstable T1 or T2 line, but that would cost nearly 10 times the amount per month that my cable modem does, for only a minor increase in available bandwidth.

Broadband in the United States needs revising, because currently it sucks nuts.
--
Chris "TunkeyMicket" Watford
pleasant broadband experience (4.00 / 3) (#21)
by FourDegreez on Tue Jul 16, 2002 at 11:44:10 AM EST

There are so many broadband horror stories, I thought I'd post a positive one.

A year ago, I signed up for Earthlink DSL ($50/month, free self-install package). My modem arrived within several weeks, and the connection worked fine right away. I'm over 10,000 ft from the teleco, yet I get over 1300/320 bps consistently. There have been no major outages, aside from the week following 9/11. I've been nothing but pleased with my service... although their customer support is not spectacular. Earthlink uses PPPoE.

Questions...
What about SDSL and IDSL? How are these functionally different from ADSL, and what makes them (or at least SDSL) superior? How about ADSL that does not use PPPoE? When does the bridged vs. routed option come in to play?

I've been thinking about switching to Speakeasy.net DSL because they offer multiple static IPs, allow servers (technically Earthlink does not forbid servers), and do not use PPPoE. What would be the ramifications of hosting one or several small websites over such a connection?

SDSL and IDSL (3.50 / 2) (#24)
by wesmills on Tue Jul 16, 2002 at 01:47:00 PM EST

I'm on an IDSL connection through Speakeasy, and I love it (not the speed, since it's only 144k, but it's all I could get .. more on why in a moment).

SDSL: This is a form of DSL that runs on its own pair of wires, and uses the full spectrum of the wire to send/receive data. The S stands for symmetrical, meaning your upload and download speeds will be exactly the same. It uses a different data encoding method on the wire that is less susceptible to interference, but, again, requires its own set of wires. (ADSL can be set to symmetrical speeds, but the A, or asymmetrical, encoding, which does not require its own wires and is more prone to distance and noise limitations, is still used) SDSL is generally available at up to 17,000' on a plain copper wire (with 384k speed).

IDSL: This is a somewhat butchered acronym standing for ISDN-DSL. The maximum speed of this connection, currently, is 144k symmetrical. It uses ISDN-style frame encoding on the wire, and its own pair of wires, to push the signal farther and through more crap on the line, than ADSL or SDSL. IDSL can also be used when there is fiber on the run from your house to the CO (also called "pairgain" or a "repeater"), as long as that equipment has the capability to handle ISDN (most do). IDSL is usually available at up to 28,000' over almost any kind of wire (only 144k speed is available, some equipment can do 160k, but I've not seen it publiclly advertised). The connection is created by taking ISDN's two B channels (64k data transfer each) and combining them with the D signalling channel (not needed on IDSL, and 16k transfer) to make 144k of available bandwidth.

I hope this helped somewhat. If you need more technical info, please see DSLReports, an excellent website for all things broadbandish.

----- Signature campaign to support K5, become a member!
[ Parent ]

SDSL and IDSL (4.00 / 2) (#25)
by TunkeyMicket on Tue Jul 16, 2002 at 01:52:21 PM EST

SDSL is Syncronous DSL, i.e. Downstream and Upstream transfers at the same speed. SDSL is move expensive, but much faster on the upstream. Many businesses host webpages on higher-end SDSL [that can range from 512kbit/512kbit to 8mbit/8mbit] rather than going with a T-line. SDSL is very very nice.

IDSL is ISDN-DSL, i.e. they bought the 2 B lines (64kbit each) and the D line (16kbit) on an ISDN circuit and merged the three together, giving you 144kbit/144kbit. Wow, isn't that a shitty speed. In Wilmington, NC 144kbit/144kbit IDSL is $80/mo. I can get 1.54mbit/512kbit ADSL for $59.99/mo, in comparison. IDSL also comes in a bonded form, where you get 4 B lines and 2 D lines bonded together for 288kbit/288kbit. Not that much better eh? They also offer the 2 B lines plus the T-1 style D line [64kbit rather than 16kbit], bringing the line speed up to 192kbit/192kbit. You can get this in the bonded version at 384kbit/384kbit. However, IDSL is always very expensive. Why? Because, ISDN lines are expensive, as far as I've noted.

On the topic of Speakeasy.net DSL, I've heard nothing but good stories about them. Getting the 1.54mbit/768kbit package is really nice from what I've heard.

Hosting web servers from cable or DSL isn't hard and is actually quite viable. I run my development server on my home machine off my cable, and it handles 10-20 concurrant users with ease. If you plan on a site getting 100-200 concurrant users, I'd plan on getting SDSL in the range of 1.54mbit/1.54mbit and up. With my [somewhat shitty] cable I host my own webpage that draws like 6 people a day, and if I post a link somewhere maybe like 300 a day. I notice no speed decrease unless someone is on my FTPd or if someone is grabbing a file via HTTPd. So don't worry 'bout it :D
--
Chris "TunkeyMicket" Watford
[ Parent ]
Same with DirectTV DSL (3.00 / 1) (#27)
by pdrap on Tue Jul 16, 2002 at 02:34:02 PM EST

They did everything right, on time. The system just works well. 1.5 megabits down, and just over the advertized 128 megabits up. And a static IP address.

And it's 50 bucks a month, with no blocked ports at all. My contract explicity says I can run servers. All their documentation says stuff like "here's our mail servers, ip xx.xx.xx.xx --- or you can just run your own if you want to"

I can definitely recommend DirectTV DSL.

[ Parent ]

DirecTV is pretty good, but... (2.00 / 1) (#29)
by 3waygeek on Tue Jul 16, 2002 at 04:34:03 PM EST

Note that the 128 kbps uplink is new -- they used to have 256 kbps uplink, at least in BellSouth territory. The ATM network is still configured for 256 kbps uplink (look at your modem's diagnostic page), but is throttled back to 128. I've been with DirecTV (and their predecessor Telocity) for 2.5 years now, and always got around 256 kbps upstream until DirecTV took over earlier this year.

Other than the artificially-reduced upstream bandwidth, the only other real issue I've had with DirecTV is their NNTP server -- it sucks big time, with poor completion and frequent renumbering of articles. I now use Usenetserver.com for my Usenet needs -- they're well connected to the DirecTV network (only a 10 ms ping, as opposed to 70 ms for DirecTV's server).

[ Parent ]
DSL probably just isn't the way to go... (3.00 / 1) (#23)
by Inhibit on Tue Jul 16, 2002 at 01:46:46 PM EST

DSL is provided over the same crappy copper lines that were run from the telco's back at the dawn of time (I exaggerate, but still :). These lines were meant to carry low frequency communications (i.e., voice) not data communications. The cost of running high speed lines to an area to make a more local CO center, then branching off that to the houses is absolutely enormous.

Cable companies, however, do not suffer from this handicap. The lines the cable co. ran into your neighborhood ten years or so ago handle bandwith in plenty, straight from their office to your domicile. Costs to get high speed data transfer kicking over these lines are minimal and mostly administrative with light kit upgrades back at the routing center. This makes cable a far more realistic and lower cost option than hacking phonelines to make them do something they were never intended to handle. (my 2 cents, thanks to the Hardware Q&A at H2K2 :)



-- Inhibit, PCBurn Linux hardware/software reviewer
Doesn't work in Oz (3.00 / 1) (#30)
by cafeman on Tue Jul 16, 2002 at 05:15:19 PM EST

That works in the US with its high cable penetration rates, but not in Oz - we don't have that cable. It's only in some suburbs. I don't know the exact number, but I'd guess the cable network covers less than 30% of Australia's population.

Copper, however, is almost everywhere (there are some towns in the outback that don't even have phone service, but there aren't many).



--------------------
"No Silicon heaven? But where would all the calculators go?"


[ Parent ]
DSL and ISP are separable services (5.00 / 8) (#28)
by isdnip on Tue Jul 16, 2002 at 03:54:02 PM EST

The topic note illustrates an important point of confusion in the world of DSL, as well as a regulatory issue that varies place to place.  DSL and the Internet services that ride atop it are two very different animals.

In the United States, we have a fairly strict system of classification of what is a "telecommunications service" vs. what is an "information service".  The latter are unregulated, full stop.  The former are regulated according to another set of classifications.

As a general rule, IP and Internet services are treated as "information", and thus unregulated.  However, IP runs on top of something -- a layer 3 protocol needs a layer 1 and 2 below it.  Layer 1 (and sometimes 2) are telecommunications.

Going back to the late '80s when I was actively involved in the development of ATM, ATM service itself was designed to be a high-speed telecommunications service suitable for many tasks. A jack of all trades, as it were.  Video was definitely part of the equation; telcos figured on ATM as a way to deliver HDTV, in competition with cable companies.  And ATM was designed to run over many different physical layers, such as SONET/SDH, E3/E4, indoor multimode fiber, etc.

ADSL was invented in the early '90s as a mid-life kicker for the old copper plant, mainly to transmit video to the home without the fiber that ATM originally needed.  It failed.  Later, ADSL was revived as a method of getting Internet access.  In many if not most cases, the ADSL network uses ATM as its multiplexing (upper layer 1) format, and AAL5 (lower layer 2) for framing.  However there are DSL networks using frame relay and other layer 2 protocols.

When an end user subscribes to an ADSL ISP, the ISP typically orders ADSL telecommunications service from a phone company.  Here's where it gets confusing.  Most telcos, including Telstra, have captive ISPs, who advertise via bill inserts, TV, etc., using their shared trademark.  So you order ISP service from Telstra's ISP arm (is it still called Big Pond?) and they, in turn, order the ADSL service from the telecom arm.  At least that's the way the US model works, and I suspect Oz is similar.  Most end users are unaware of the middle role played by the telco.

Other ISPs can order ADSL from the telephone company, and should get exactly the same treatment as the captive ISP.  Of course if the captive ISP and its parent telco agree to use PPPoE or L2TP or any other hack, then other ISPs may have to put up with it, like it or not.  That's "fair", in theory, though of course we know better.

ATM itself is our friend here.  It creates a multiplexing layer below IP, so that multiple ISPs can share the ATM network without letting the telco so much as see the other ISPs' IP layer.  (Frame Relay can do the same thing, though it's geared towards slower total speeds, and is thus more likely to be found in rural areas.)  Each ISP would thus get its own VP/VCs.  In theory, PPPoE woudln't be needed by every ISP.  But the way some DSL is implemented, everybody has to use it.  Whether PPPoE is good or bad is, well, debateable.  Raw IP DSLAMs do exist, but would shut out competition from non-telco ISPs!  You don't want to go there. Mostly they're used by European monopolist, and by small competitive ISP-CLECs.

So far, we're simply establishing competition at the ISP level, for multiple users of the telco's DSL service.  I should point out that while this is the law in the USA now, there is a proceeding at the FCC to change this and let telcos kick off competing ISPs!  My hunch is that if the FCC were to let this go ahead (by no means certain), antitrust law would step in big time, due to "tying" laws, but that's another tale.

Now we do also have competition in the USA for the raw telecom service.  CLECs can lease the ILEC copper loops and put their own DSLAMs into the central offices.  We had a lot of CLECs do this between 1997 and 2000.  So many, in fact, that they divided the market too many ways and drove each other bankrupt.  Now we have the ILEC, Covad (alive after Chapter 11), and some small regional operators left.  The ILECs have the bulk of residential subscribers, mostly on their own ISPs (the biggest are Verizon Online and Prodigy) but with some other ISPs too.  Covad has some residential and some business customers, and many ISPs.

An ISP cannot do DSL by itself, but its owner can create a CLEC affiliate for the purpose.  This works in some areas; I know of little rural ISPs with profitable clusters of DSL in small towns.  But you need at least a couple hundred subscribers to make a CO profitable.  And with only around half of the the lines in the USA "loop qualified" for DSL, fewer in rural/suburban areas, it's a tough business.  And there are bills in Congress (Dingell-Tauzin) which would basically put DSL CLECs out of business, giving the incumbents (Bells) unregulated monopolies.  Fortunately those bills have little chance of passage.

I don't know if Oz allows competing DSL providers to share the loop, or on what terms.  But that's a different question from how Telstra lets ISPs use its DSL service.


I see... (5.00 / 1) (#34)
by Mike Hunt on Tue Jul 16, 2002 at 08:04:05 PM EST


Thankyou for the clarification.  I had no idea what the US status quo was, apart from a few horror stories I had heard about competing carriers being screwed by the bells...

Australia also differentiates between carriers and ISPs.  A 'carrier' is defined in the Telecommunications Act 1997 as anybody who _owns_ a communications circuit which is publically accessible longer than 500 metres (1600 odd feet.)  Carriers must obtain a 'carrier's license' from the Australian Communications Authority (a feat which costs tens of thousands of $AU, and imposes certain liabilities on the carrier, such as minimum QoS and law enforcement access to the facilities provided.)

As a result, 99% of ISPs in Aus are NOT carriers, but merely operate over infrastructure provided by one (usually Telstra, sometimes Optus, rarely others.)  

I guess the point of this article was 'given that Telstra is the incumbent with the ADSL infrastructure tied up, how can it be made more competitive?'  The problem is that Telstra has a conflict of interest; they want Big Pond to be the monopoly DSL provider, but have to guarantee a minimum level of competition (due to other ACA provisions.)

MH.

I used to have a .sig, but the government told me it would cause cancer.
[ Parent ]

You guys don't know your luck... (none / 0) (#35)
by bricks on Thu Aug 15, 2002 at 07:43:02 AM EST

In Ireland we have Eircom, Their Cheapest ADSL package is 110Euros/Month and thats with a 3 Gigabyte/month download limit (512k/128k).

ADSL Done Wrong: Technological Impediments to Consumer Broadband | 36 comments (33 topical, 3 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest Đ 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!