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

[Chad Thomsen]

Thanks folks.  Just as I intially though before I even posted the question,
this is just a bit to risky to do for the cost benifit.  Looks like I am
going to stay with the frame relay.  I do appreciate everybodies input and
explanaitions.  Interesting conversation going on here.

On 2/1/06, Ryan Leathers <ryan.leathers at globalknowledge.com> wrote:
>
> 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/
>