[TriLUG] Site to Site VPN over the net? Good enough for VoIP?

[Ryan Leathers]

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/