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

[Ryan Leathers]

Good call Chad.  If you've got Frame Relay in place, its meeting your
needs well, and you're not being beaten up too badly to cut costs, then
by all means stick with Frame.  Its an excellent technology.  I used to
do a lot of consulting for folks who thought their Frame networks were
broken, or their providers were rotten.  I'd say in at least 9 of 10
cases the problems turned out to be a failure to understand how traffic
shaping should be used with Frame.  

On Wed, 2006-02-01 at 12:42 -0500, Chad Thomsen wrote:
> 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/
> >