[GTER] Gestão de tráfego FTTH

Tue Jun 25 13:24:10 -03 2013

No caso de concorrência pelo compartilhamento, ela atende a um mercado
diferente daquele cujo serviço está sendo ofertado. Talvez seja o caso de
oferecer também planos mais baratos (se for objetivo da empresa servir a
esse nicho também).

Abs, Leandro

Em 23 de junho de 2013 11:46, Klemenson Leal Anacleto
<klemenson at gmail.com>escreveu:

> >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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>