<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 December 2014 at 18:01, Mark Tinka <span dir="ltr"><<a href="mailto:mark.tinka@seacom.mu" target="_blank">mark.tinka@seacom.mu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, December 22, 2014 02:09:45 PM Kofi ANSA AKUFO<br>
wrote:<br>
<br>
> I quite remember one company - DiViNetworks<br>
> <<a href="http://bgp.he.net/AS57731#_peers" target="_blank">http://bgp.he.net/AS57731#_peers</a>> - which was selling<br>
> some form of patented bandwidth optimization (which<br>
> caching in general addresses -" flag repititive data<br>
> patterns to speed up delivery and also optimize<br>
> bandwidth utilization) solution which identifies bit<br>
> patterns or streams instead of files or web objects. I<br>
> noticed many ISPs around the globe<br>
> <<a href="http://bgp.he.net/AS57731#_peers" target="_blank">http://bgp.he.net/AS57731#_peers</a>> currently subscribe<br>
> to their service especially when they reach 90 -95% of<br>
> their upstream capacity (usually their DS3 and STM1<br>
> internet transit capacity) to gain extra 50% on<br>
> bandwidth. At least that is the selling benefits.<br>
<br>
My issue with these bandwidth managers is that they<br>
generally assume a very small network, possibly located in<br>
only one city with normally one (and not more than two)<br>
upstream connections.<br>
<br>
Large scale networks that are not centralized (i.e., traffic<br>
enters or exists the network at any point across the entire<br>
topology) do not work well with bandwidth managers.<br>
<br></blockquote><div> </div><div>I believe architectural wise for carrier networks it is prudent to avoid in-line or in-route bandwidth optimization technology due to cost of scalability and maintainance - and this is mostly addressed in current well designed architectures.<br><br></div><div>What we see now as pointed out are bandwidth optimization technology which must not be confused with CDNs. In essence these distributed bandwidth optimization technologies peer with Tier 1 transit providers and provide agent appliances which are deployed in clients networks.(They are not deployed in-line logically hence do not affect multi-homed architectures physically or logically)<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, operators still deploy them close to customers to<br>
provide usage-based services, traffic monitoring/management,<br>
e.t.c. But because of the nature of large networks, you<br>
can't centralize this without getting into serious problems;<br>
so some vendor gets stinking rich because you end up having<br>
to distribute this middleware as a way to solve the scaling<br>
issue.<br>
<br></blockquote><div>Well that seems to be the trend now - X as a Service (XaaS) - which primarily seeks to decentralize and optimize resource provisioning through centralized management and milk enough from clients :).<br><br>I do agree though that there are the "old-school" bandwidth managers which small ISPs and corporate entities still deployment.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally, if I can't do it in the router (or to a device<br>
that can be out-of-path), I won't touch it.<br>
<br>
I stopped using centralized bandwidth managers in 2006<br>
(which is not to say they are useless - if you have a very<br>
small network with only one upstream and 99.999% of your<br>
traffic goes out to/comes in from that upstream, then they<br>
make sense).<br>
<span class="HOEnZb"><font color="#888888"><br>
Mark.<br></font></span></blockquote><div><br> <br></div></div><br></div></div>