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

Wed Feb 1 15:14:21 EST 2006

I would love to look into traffic shaping devices but it is VERY expensive
last time we looked at it which was a few years ago.  Don't know if my
company would go for it beause we first need some infrastructure upgrades
here.  We are still running hubs at a few locations... YIKES!!!

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