[NCLUG] DSL Throttling or General Congestion?

[Sean Reifschneider]

On Tue, Nov 21, 2006 at 11:56:25AM -0700, Stephen Warren wrote:
>switch at the nearest CO (central office), and that ATM line is then
>routed, in isolation, to the ISP. Only then does the ATM traffic get

That's not entirely true.  ATM is more like Frame Relay in bandwidth.  You
can pay for different levels of bandwidth on ATM, in their equivalent of
"CIR".  I forget the ATM names for that idea, but when you buy 10mbps of
ATM bandwidth, you can get it in several different ways, which vary your
priority on the network.  Meaning that if there's congestion on the
network, depending on your priority, you may get lost packets even though
you're within your peak bandwidth.

With DSL, QWest calls the ISP end-point of the ATM connection a
"megacentral", and you buy megabits on that as well.  When I was running
one of these, we were getting 3mbps of megacentral bandwidth, and tested it
with 3 or 4 different DSL lines, and found that we could burst above that
level.  However, if there's congestion, I'd imagine that it might be
reduced down to that 3mbps committed rate.

The Megacentral bandwidth algorithms were never really explained very well
to us by QWest.

>The thing about ATM is that it's time division multiplexing, so there's
>an assigned fixed-bandwidth link all the way from your DSL modem at home
>all the way to the ISP.

Not at all true.  We had more than 25 users, which at 1.5mbps is more than
the 35mbps we had on the DS-3, after you took off the 10mbps that was used
for transit.

>As such, there's no opportunity for any kind of modem-modem interference
>(or anything else) until your traffic actually gets to the ISP's own
>equipment.

Actually, there is.  Cross-talk issues in a single cable bundle with
multiple DSL lines on it are the reason they switched encoding years ago,
and are the reason that you had to switch from Cisco 675s to Cisco 678s.
IIRC, one of the encodings was called CAP.

Once it's at the DSLAM (what you call the "switch at the nearest CO" above,
it doesn't actually have to be at the CO, but QWest has been reluctant to
put them in remote terminals for various reasons, other telcos definitely
do), it gets put on the ATM network, where it's subject to congestion,
similar to how Frame Relay is.

>I suppose it's possible for the ATM session to be terminated directly in
>the CO, and then to have, say, a GigE backhaul to the ISP, but I don't

ATM isn't a line, it's an encoding.  They wouldn't normally transit it over
GigE, because the phone company can't transit ANYTHING over Ethernet.  They
instead pass it over a T1, DS-3, OC-3, or other sort of transit to the ISP.
The one we had at NCIC was over an OC-3 that was then broken out into 3
DS-3s for the last dozen feet in our facility.

If it was congestion on the ATM cloud, everyone would be seeing the issue
roughly equally in a particular geographic region.  Since it doesn't seem
to be the case here, I'm imagining it's at the ISP.

I actually switched our DSL line over to MSN a month or so ago, but never
received password information so I haven't used it at all.  One of these
days I should connect it and get it working, or just cancel the line.

Thanks,
Sean
-- 
 "I mean, I know we don't have any customers, but I thought that was a
 bad thing...  Not like, a business strategy."  -- _High_Fidelity_
Sean Reifschneider, Member of Technical Staff <jafo at tummy.com>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability