[afnog] privacy vs caching

[Kofi ANSA AKUFO]

On 22 December 2014 at 18:01, Mark Tinka <mark.tinka at seacom.mu> wrote:

> On Monday, December 22, 2014 02:09:45 PM Kofi ANSA AKUFO
> wrote:
>
> > I quite remember one company - DiViNetworks
> > <http://bgp.he.net/AS57731#_peers> - which was selling
> > some form of patented bandwidth optimization (which
> > caching in general addresses -" flag repititive data
> > patterns to speed up delivery and also optimize
> > bandwidth utilization) solution which identifies bit
> > patterns or streams instead of files or web objects. I
> > noticed many ISPs around the globe
> > <http://bgp.he.net/AS57731#_peers> currently subscribe
> > to their service especially when they reach 90 -95% of
> > their upstream capacity (usually their DS3 and STM1
> > internet transit capacity) to gain extra 50% on
> > bandwidth. At least that is the selling benefits.
>
> My issue with these bandwidth managers is that they
> generally assume a very small network, possibly located in
> only one city with normally one (and not more than two)
> upstream connections.
>
> Large scale networks that are not centralized (i.e., traffic
> enters or exists the network at any point across the entire
> topology) do not work well with bandwidth managers.
>
>
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.

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)



> That said, operators still deploy them close to customers to
> provide usage-based services, traffic monitoring/management,
> e.t.c. But because of the nature of large networks, you
> can't centralize this without getting into serious problems;
> so some vendor gets stinking rich because you end up having
> to distribute this middleware as a way to solve the scaling
> issue.
>
> 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 :).

I do agree though that there are the "old-school" bandwidth managers which
small ISPs and corporate entities still deployment.



> Personally, if I can't do it in the router (or to a device
> that can be out-of-path), I won't touch it.
>
> I stopped using centralized bandwidth managers in 2006
> (which is not to say they are useless - if you have a very
> small network with only one upstream and 99.999% of your
> traffic goes out to/comes in from that upstream, then they
> make sense).
>
> Mark.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://afnog.org/pipermail/afnog/attachments/20141222/a14129fb/attachment.html>