[GTER] Compressores de dados (Peribit/Juniper e assemelhados), o retorno

[Rubens Kuhl Jr.]

> a) para manter a disponibilidade e a performance do circuito as caixas
> precisam estar em "cluster" ou em redundância nas duas extremidades; se
> usada apenas uma caixa em cada ponta, e uma delas pifar, a compressão
> "some" instantaneamente, o que é péssimo em circuitos já saturados; em
> outras palavras, a coisa pode não ser tão barata quanto se diz;

A compressão some mas o circuito não cai...


> b) é preciso contratar capacidade adicional, com uma previsão de
> "sobra", porque se o tráfego aumentar e exceder a capacidade contratada
> o tráfego excedente vai para o circuito sem compressão (no caso das
> antigas Peribit era assim);

Acho que ainda é assim, pelo que me descreveu um canal da Juniper
especializado na família que era Peribit.


> c) tráfego já com características de compressão (streams de áudio e de
> vídeo) podem não ser beneficiados (e nesses casos a caixa não seria uma
> introdutora de latência?);

Depende, qual a latência do circuito ? A maior utilidade dessas caixas
é com circuitos de satélite cuja latência é brutal, a da caixa é o
menor dos seus problemas...

Também no caso de satélite, é bom pedir uma conexão separada para
multicast, onde podem ser colocados streams de forma cost-effective
para as unidades.

> d) os algoritmos são proprietários e as caixas de diferentes
> fabricantes não interoperam entre si; e

Para que um só padrão quando você pode ter um montão ? :-)


> e) se o ponto remoto está longe (por exemplo, lá em Rondônia, no meio
> da floresta), sem "clustering" das caixas, e uma das instaladas nas
> pontas "pifa", até haver o reparo seu circuito pode voltar 'a situação
> antiga (talvez de saturação).

Situação essa que continuaria mesmo sem a caixa, pois o custo
recorrente de um circuito desses já faria com que não fosse feito
upgrade...


Rubens