I think you missed something Jim - Jon is contrasting the merits of a leased line with a shared connection (VPN or NO-VPN). More than this, the selection of the leased line technology/provider is relevant. Placement of a switch/gateway/proxy or whatever is one matter, the network facilities are another.
There are important differences in the technologies which you are overlooking. L3 decisions made at one or several routers end-to-end may contribute less to variable latency than the access loop itself, or the aggregation edge (PPP->Ethernet->ATM->DSL) chores. I think Jon was trying to point this out, but he didn't say it as plainly as I will: You can apply all the QoS and bonding and trunking you want to in your LAN, or private WAN to improve performance of any particular traffic, but if you have selected your network technology on any basis other than suitability to the nature of the traffic you'll be passing then you've basically just rolled the dice. (This is getting way off topic, sorry if its too far) Let's consider DSL... DSL, (referring to ADSL T1.413-I2/G.992.1-2) has an inherent variable latency by design. It is the expectation that a SNR measurable on a given pair will constantly fluctuate due to ever-changing perturbations in the binder. To deal with this, post-training, near end and far end counters (NEBE/FEBE) keep track of error ratios. The frame also has built-in error correction, but this isn't sufficient in all cases. No mechanism exists for retransmission at this low layer, leaving this to a relatively slow upper layer operation, if at all. Instead, the best that can be hoped for when loop conditions change is to determine the optimal constellation density in each freq bin and go with it. How often is this happening? Well it depends entirely on your particular local loop and the other services in the same (and on adjacent) binders. Example: A classic T1 or an ISDN BRI are both perfectly hideous neighbors due to their old-fashioned digital signaling techniques. By contrast, if you take a group of binders that deliver only POTS and ADSL then you'll have far more favorable and consistent SNR, generally (If you can recall ever taking a phone off hook and faintly hearing another conversation, then you know its not perfect). So, Jon's spotty / inconsistent experience with DSL is what I'd expect. Its typical of the technology. This is a fine situation for many types of data which need to be transmitted as quickly as possible but are not particularly sensitive to variable latency. It is ok, but less than ideal for something like VoIP. Why are some better than others? A better local loop makes all the difference. As an SP, If you don't own the outside plant, but you can lease conditioned facilities, then you can probably offer a more consistent service than the owner of the plant who uses whatever happens to muster a loop test. Next, what happens at or immediately beyond the DSLAM is important. This is where resource scarcity (queuing) and multi-layer encapsulation and forwarding take place. An overused/underpowered DSL aggregation node will add more latency just dealing with encapsulation than a router L3 decision with CEF or something. Finally, there is the obvious problem of bandwidth scarcity at the aggregation point which could plague any technology more or less equally, but is determined by a service provider's stinginess, so folks tend to look at it as an attribute of the technology that provider sells. Time to get back to work. Peace, Ryan On Tue, 2006-01-31 at 17:31 -0500, Jim Ray wrote: > if you're hopping over from network to network, it really doesn't matter > what any one site has. the combination of all gate delays creates the > latency. if any network in the chain has a bottleneck, you'll still > experience latency. when you have control over the network and can > implement p and q tagging, you can minimize the effects of latency on a > local basis. anything over the Internet will be more susceptible to > latency. > > Jon Carnes wrote: > > >On Tue, 2006-01-31 at 15:06, Jim Ray wrote: > > > > > >>it doesn't matter so much that it is hosted or on the premises of the > >>corporate headquarters. it's the pipe between the two and the latentcy > >>that count. > >> > >>jonc wrote: > >> > >> > >> > >>>If you are connecting multiple sites then your best bet is to use a > >>>hosted provider. > >>> > >>> > >>> > >>> > >That would be true if the casual business could afford to buy the types > >of Softswitches and Border Controllers (Voice Proxy Firewalls) that a > >Hosted Provider has in place. > > > >If he hosted the softswitch and all his sites connected via Speakeasy > >then they would sound better - since the traffic would most likely never > >leave Speakeasy for the cloud - but they would not have QoS applied for > >their traffic (unless they were going directly to Speakeasy's > >softswitches), so while the voice would probably sound good it wouldn't > >sound as clear as going with a hosted solution. > > > >The best solution (if he hosts the Softswitch directly) is to have a > >dedicated line from one ISP that feeds the VoIP traffic to the > >softswitch, and then use a separate ISP for internet access. > > > >We run some Soho clients this way. They have DSL for their data needs > >and use TW for their VoIP connections. We do it this way because VoIP > >never uses enough bandwidth to cause any restrictions (Bandwidth > >queueing that is) on the head cable router - so the latencies stay > >within a nice range. > > > >The latencies on a DSL connection from Bell are very unpredictable - > >even when there is no load. Verzion's DSL is generally better. Sprint's > >seems to cycle from okay to horrible, leading me to believe that they > >have absolutely no management on their network access points. > > > >Speakeasy does a really good job - much better than TimeWarner. > >Unfortunately they aren't available everywhere - and some places where > >they have a presence they aren't accepting any new customers - so they > >don't overload their networks (what a concept!). > > > >Speaking from the front lines of VoIP, > > > >Jon Carnes > >FeatureTel > > > > > > > > > -- > TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug > TriLUG Organizational FAQ : http://trilug.org/faq/ > TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
