[asterisk-users] Moving from DSL to T1

[Joel Maslak]

On Mon, Sep 13, 2010 at 1:32 AM, Kevin Keane <subscription at kkeane.com>wrote:

My numbers are from an AT&T DSL line in California, suburban San Diego
> county, and just around the corner from the central office. So it is not the
> distance (with DSL, the distance does make quite a difference). On the other
> hand, there are several hops just to get to the Internet backbone.
>

Lots of misconceptions in this thread.  I'll limit this discussion to what I
know - ADSL, T1, and cable as delivered by US telcos/ISPs.

I just measured my Denver, CO Qwest DSL line.  I have a short DSL line -
about 4 city blocks, but then, like most metro areas served by Qwest, once
my connection ends up in the exchange, I'm backhauled about 30 miles via ATM
to the actual edge router(s) that serve the metro area (the edge router is
not in the central office).:

10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 28.646/31.359/33.828/1.603 ms

This is pretty typical of Qwest DSL in Colorado and Wyoming.  I've literally
run hundreds of DSL sites in these states, and find that the DSL product is
a great bargain for business (I usually didn't run it to Qwest's edge router
but to my own corporate routers, as basically an ATM circuit that just
happens to be delivered on DSL).  I ran a large video conferencing network
on it without any issues (H323).

The reason for the times being around 30 ms round trip is that Qwest uses
interleaving on the DSL circuit.  It's on for a reason (it makes TCP streams
faster - instead of retransmitting whole 1500 byte TCP packets, the system
retransmits the 53 byte ATM cell instead. It might have to do that several
times, for several packets that get corrupted, but it will still be faster
than TCP dealing with the loss.  Of course VoIP doesn't use TCP, nor does it
need 100% guaranteed packet delivery.  But this also can help with jitter,
depending on what else is on the line.  Typical T1s do not do this
interleaving (they are better engineered, regardless of whether they are
delivered on true T1 media or backhauled via HDSL - either way, the packets
make it out the other end a lot more reliably than they do on ADSL
connections).

For DSL, there are no shared connections between the telephone exchange and
the home - everything there is dedicated.  Cable shares a connection with
your neighbors.  T1 is dedicated to the Exchange as well (burstable or
dedicated bandwidth both).

At the Exchange, DSL is aggregated on a large (OC3 typically) ATM circuit to
get transported to the ISP (or telco's own) edge router.  This is shared
bandwidth with everyone else on the same DSLAM.  A point-to-point T1 has
dedicated bandwidth (no aggregation) to the ISP.  A frame relay, MPLS, or
ATM T1 has the amount of dedicated bandwidth you pay for (in my experience,
usually none, as that's cheapest) with the rest of the bandwidth provided if
there is capacity on that ATM circuit between the central office and the
ISP/telco edge router.  Cable is also usually aggregated at some
intermediate point, similar to DSL.  Once connected to the ISP edge router,
all circuits are aggregated out to the internet backbone via a connection
smaller than the sum of all the subscriber bandwidths.

So, frame relay, MPLS, and ATM T1s - as typically ordered - often function
like DSL, with the same choke points.  Even a point-to-point T1 that goes
"to the internet" however will hit a choke point and might have packet loss
- no matter how much you paid for the T1 (the internet backbone itself has
packet loss and choke points).

Cable has an additional choke point (subscriber loop).

Now, hopefully the ISP and telco have engineered everything to not have
significant choke points and you'll never have a capacity problem (the same
goes with their peering connections - hopefully they, too, are big enough).
But even an MPLS burstable T1 could perform badly at high capacity times.

Most of these choke points (such as the DSL DSLAM to edge router) do know to
not let one user monopolize the uplink, but to let each user have the same
approximate capacity when there is congestion.  So someone with say only one
VoIP call won't experience packet loss or changes, while another user
downloading a movie will see a slower download.  (in the IP world, this is
called "fair queuing" - in the ATM world, it goes by other names; they idea
is that you should give everyone the same amount of possible bandwidth in a
congestion situation, even if they aren't using all of that bandwidth).

Most of these technologies do not let you apply QoS to the choke points
effectively.  So you are left with point-to-point T1s or other T1s that you
buy with guaranteed (more expensive) bandwidth.  But you can't QoS across
the internet.  Sure, you can do some traffic shaping on a DSL line, and
it'll work good most of the time, but there are no guarantees with
guaranteed bandwidth!

So, the only way to gaurantee packet delivery is to build your voice IP
network like you would have built a TDM network - dedicated bandwidth
between you and wherever the call terminates into the PSTN, not using the
internet at all, and not using low cost circuits (like any circuit that goes
"to the internet").  That's what large corporations do - typically a
separate voice point-to-point T1 just for voice between each of their sites,
and then terminating to the PSTN via TDM.  It's the best possible way to
guarantee toll quality.

But from a practical standpoint, DSL looks a lot like a frame/MPLS/ATM T1
with a burstable rate.  Just different speed profiles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100913/d447ee2a/attachment.htm