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