On Mon, Sep 13, 2010 at 1:32 AM, Kevin Keane <span dir="ltr"><<a href="mailto:subscription@kkeane.com">subscription@kkeane.com</a>></span> wrote:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
</blockquote><div><br>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.<br><br>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).:<br>
<br>10 packets transmitted, 10 packets received, 0.0% packet loss<br>round-trip min/avg/max/stddev = 28.646/31.359/33.828/1.603 ms<br><br>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).<br>
<br>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).<br>
<br>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).<br>
<br>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.<br>
<br>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).<br>
<br>Cable has an additional choke point (subscriber loop).<br><br>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.<br><br>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).<br>
<br>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!<br>
<br>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.<br>
<br>But from a practical standpoint, DSL looks a lot like a frame/MPLS/ATM T1 with a burstable rate. Just different speed profiles.<br></div></div>