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 <[EMAIL PROTECTED]> 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/
