[GTER] Gestão de tráfego FTTH

Vinícius Garcia lgarcia.vinicius at gmail.com
Thu Jun 20 18:31:43 -03 2013


Também acho que o limite de conexões junto do burst seria algo adequado.
Quanto a hardware, não tem muito milagre mesmo, mas dai o que mais
consumiria talvez seja o limite de conexões. Talvez alguma coisa mais
inteligente com avisos de heavy users tanto de banda quanto de conexões
seria um termômetro sobre usuários que estão compartilhando, cabendo regras
"especiais" para esses talvez.

O que as gigantes fazem nesse caso de shaping, alguém sabe? Acho que eles
não entregam tudo assim de mão beijada (lógico, as que não tem .franquia).

[]'s

Em 20 de junho de 2013 11:55, Marcio Dias <marcio at dbug.com.br> escreveu:

> Sofremos o mesmo dilema. Alguem?
>
> []'s
>
>
> Em 18 de junho de 2013 10:15, rmcarv <rmcarv at gmail.com> escreveu:
>
> > Pessoal,
> >
> > Estamos realizando alguns projetos aonde iremos entregar um volume grande
> > de banda aos assinantes. Teremos planos de 35, 50 e até 100mb por
> > assinante.
> >
> > A idéia desses planos é garantir ao usuário RESIDENCIAL, uma experiência
> > diferenciada. O grande "calcanhar de aquiles" desse projeto e como fazer
> a
> > gestão dessa banda de forma que os assinantes não utilizem para REVENDA
> ou
> > COMPARTILHAMENTO com o bairro todo.
> >
> > Por exemplo, se disponibilizarmos a um assinante 50mb, ele pode
> facilmente
> > compartilhar essa banda com 10 pessoas (ou mais) ou ainda provedores
> > concorrentes podem comprar nossos planos para utilização como Uplink
> deles.
> >
> > Existem algumas políticas que estamos estudando mas nenhuma delas nos
> > parece realmente robusta. Talvez a solução seja a soma delas. Gostaria de
> > trocar experiências  e saber quais políticas vocês tem adotado em suas
> > redes de forma a manter o uso de banda equilibrado com o foco no produto
> > RESIDENCIAL.
> >
> > As opções que temos discutido hoje são:
> >
> > *1) Franquia de tráfego *- Modelo usado pela Net hoje. Simplifica tudo
> mas
> > cria uma barreira comercial com o cliente, em especial quando se
> enfrenta a
> > GVT a qual é agressiva  no seu marketing informando que não possui
> franquia
> > alguma
> >
> > *2) Limite de banda com BURST* - Para um volume maior de clientes,
> > imaginamos um consumo de hardware muito grande e não temos certeza o quão
> > escalável é essa alternativa. Teríamos que definir valores muito bem
> > ajustados para que o cliente tenha uma banda adequada e em casos como
> vídeo
> > online (NETFLIX), por exemplo, o BURST não se aplica pois a conexão é
> > contínua e o cliente terá sua banda achatada.
> >
> > *3) Limite de conexões simultâneas -* Muito se fala mas achar uma razão
> > compatível com um assinante residencial nos parece muito difícil. Também
> > não conhecemos ninguém que utilize esse tipo de gerência em sua rede e
> que
> > possa trocar experiência. Além disso, hoje quando se abre um aplicativo
> de
> > P2P o número de conexões que ele abre é altíssimo. Com um recurso desses,
> > poderia-se derrubar a rede de um cliente quando ele abre um cliente P2P.
> >
> > *4) Limitar o TTL -  *Acreditamos que a alteração do TTL pode ser
> > facilmente burlada, não parecendo ter uma confiança que justifique tratar
> > na rede.
> >
> > *5) Restringir Upload -  *Um Upload baixo acaba gerando uma experiência
> de
> > navegação ruim com um volume maior de usuários. O problema disso é que
> uma
> > das idéias deste projeto é justamente dar um volume de Upload alto aos
> > usuários de forma que a experiência de navegação seja realmente
> > excepcional.
> >
> > Enfim, quais as opiniões e experiências de vocês ? Alguma sugestão sobre
> um
> > modelo de gestão da banda com altos valores (30 mega, 50 mega, 100 mega)
> ?
> >
> > Grande Abraço!
> >
> > Rodrigo Carvalhaes
> > TRIADE TELECOM
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Marcio Fraisleben Dias
> ;DBUG Telecom
> 42 3252 2306
> 42 8806 8865
> 42 8813 5401
> 41 9879 1853
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Vinicius Garcia



More information about the gter mailing list