[GTER] Gestão de tráfego FTTH

Sun Jun 23 11:46:40 -03 2013

>Afinal, qual é
>a diferença entre um usuário que deixa o p2p aberto o tempo todo e o
>usuário que compartilha a Internet com os vizinhos?

Ao meu ver, o problema maior não é o uso da banda, mais o compartilhamento
traz um outro prejuízo... Se um determinado cliente compartilha com mais 5,
estes 5 (ou pelo menos 1 dos 5) poderiam ser novos clientes da empresa...
Ou seja a empresa está em teoria deixando de pelo menos ter a possibilidade
de vir a ter aqueles como cliente direto...

E se isso se repete, imagine 20 compartilhando com 5? A soma são 100 que
poderiam ser clientes da empresa....

Klemenson Leal

Em 23 de junho de 2013 09:50, Leandro Pereira de Lima e Silva <
leandro at limaesilva.com.br> escreveu:

> Já tive uma solução em que os usuários precisavam se autenticar via web.
> Basta um script bem feito para criar um autenticador automático. E aí se o
> sujeito quiser revender ele coloca esse script num gateway Linux.
>
> Acho que a solução mais honesta é ser claro quanto às especificações
> técnicas do serviço que você está vendendo.
>
> Se você está disposto a permitir alguém usando a sua banda 100% do tempo,
> deixa sem limite de tráfego. Se não está limita por tráfego. Afinal, qual é
> a diferença entre um usuário que deixa o p2p aberto o tempo todo e o
> usuário que compartilha a Internet com os vizinhos?
>
> O autenticador ainda tem a inconveniência de ir contra o modelo em que a
> Internet deve estar disponível para que diversos equipamentos na residência
> do sujeito se conectem a ela sob demanda.
>
> Abs, Leandro
>
> Em domingo, 23 de junho de 2013, Fábio Schorn escreveu:
>
> > Amigo,
> >
> >     Contrate um grupo de desenvolvedores e programe um gerenciador de
> > conexões, que os usuários vão utilizar para autenticar na sua rede e
> assim
> > liberar o consumo de banda cabível a cada plano contratado e com login
> > único
> > ou simultâneo dependendo do plano do usuário. É somente uma ideia, mas
> acho
> > que poderia dar certo e é inovador!
> >
> > Atte,
> >
> > Fábio Schorn
> >
> > >>
> > >>
> > >> Em 18 de junho de 2013 10:15, rmcarv <rmcarv at gmail.com<javascript:;>>
> > 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
> > >>
> > >
> > >
> >
> > --
> > Eng. Fabio Roberto
> > *S.O DO BRASIL TELECOMUNICACOES*
> > /www.superonda.com.br | www.zamix.com.br /
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> > -----
> > Nenhum vírus encontrado nessa mensagem.
> > Verificado por AVG - www.avgbrasil.com.br
> > Versão: 2013.0.3345 / Banco de dados de vírus: 3199/6431 - Data de
> > Lançamento: 06/22/13
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Klemenson L. Anacleto