[GTER] RES: RES: RES: Petição para Internet sem Limite de Trafego.

Tue Jan 24 08:29:52 -02 2017

On Jan 23, 2017 6:21 PM, "Israel Ramos" <israel.melo.ramos at gmail.com> wrote:

Flavio,

Quando me refiro a amostragem quero dizer o seguinte: Imagine que entre
você e seu cliente existam 2 ou 3 switches ou qualquer outro tipo de
equipamento realizando a ponte. Se você realizar a medição nas duas pontas
as amostragens são diferentes. Se houver perda de pacotes entre qualquer um
dos seguimentos já não haverá mais simetria entre os valores medidos nas
duas pontas. Independente se você está contabilizando por taxa de
transferência ou por total de bits ou pacotes trafegados. E para o caso da
medição por taxa de transferência é pior ainda a situação, já que
geralmente os mecanismos funcionam com amostragem de tempo.

Não entendi, mas se você diz que o modelo de taxa de transferência é pior
esse argumento me aprece a favor do possibilidade do uso de franquia de
transferência, certo?

Hidrômetro e Medidores de Energia Elétrica são obrigatoriamente
equipamentos homologados. Eles são instalados na casa do cliente. Esses
equipamentos medem precisamente a quantidade de carga ou volume de água que
passa da rede pública para a rede privada. A rede publica é
responsabilidade da empresa fornecedora e a privada do cliente. Esses
equipamentos são instalados exatamente na fronteira entre as duas redes,
logo entende-se que tudo que passa de uma rede para outra é contabilizado.
O cliente tem acesso em tempo real aos dados contabilizados.

Se você for cobrar por trafego, onde estará localizado o equipamento ou
software que fará a medição?

Uma idéia seria no CPE, mas o que cogitei foi a de existirem equipamentos
homologados que o cliente possa usar para confrontar a medição das
operadoras, assim a operadora deveria acatar uma contestação evidênciadas
em roteado/accesss homologados. Mas é apenas uma ideia.

Definida essa localização, qual técnica vc usará pra contabilizar somente
"bytes" reais de consumo. Descartando bytes de pacotes perdidos, bytes de
autenticação, bytes de heartbeat (monitoramento e afins), bytes de
multicast, bytes de re-tentativas de conexão, etc, etc, etc, etc, etc.

Isso faz parte do consumo,  no modelo atual essas variáveis não são
descontadas da taxa de transferência do plano. Não adquirimos links de
10mpbs descartados overhead. Com relação a perda de pacotes isso degrada o
uso normal do serviço e cabe uma abertura de chamado para solucionar o
incidente.

Fora essas questões estritamente técnicas ainda existem as questões
humanas, o comportamento do usuário por exemplo que tecla F5 se um site
demora mais que 5 segundos para carregar. (mas tudo bem, ignore isso por
enquanto).

Enfim...

On Mon, 23 Jan 2017 at 12:06 Flavio Rescia Dias <flavioresciadias at gmail.com>
wrote:

> Israel,
>
> Discordo um pouco (novamente =D), seguem minhas considerações:
>
> On Jan 21, 2017 10:33 PM, "Israel Ramos" <israel.melo.ramos at gmail.com>
> wrote:
>
> Flavio,
>
> Não há maneira precisa, coerente e linear para realizar o controle da
> quantidade de "bits" você está consome se medidos em pontas diferentes da
> rede.
>
> A medição de tráfego é realizada por amostragem.
>
>
> Talvez me falte conhecimento técnico nesse ponto, por que amostragem?
> Acredito, até agora, que taxa de transferência é amostragem a não ser que
> seu intervalo seja de 1seg para bps, mas ai tem burst, etc. Bits
> transferido me parece algo absoluto não?
>
> Estando ciente deste
> ponto já sabemos que teremos problemas com divergências nas aferições. E
> isso e um dos primeiros problemas para se preocupar.
>
>
> Concordo, mas isso já existe com água, gás e luz, por exemplo.
>
>
> Indo um pouco além, profissionais que trabalham com TI e que entendam o
> básico sobre os principais protocolos (TCP/IP, UDP, HTTP, e etc) sabem que
> a internet é construída para ser resiliente, tolerante a falhas o que
> reflete diretamente em reenvio de pacotes, handshake de conexão,
mecanismos
> de time out, multicast, etc, etc. Fora a questão do reenvio de pacotes
> existem também as diferentes técnicas de compressão de arquivos,
> transmissão de dados, construção de sites, utilização de webservices,
> integração de serviços, coleta de estatísticas, refresh automático de
> página, pré carregamento de imagens, carregamento de anúncios, cache e
mais
> uma infinidade de coisas que acontecem nos bastidores e que consomem
> tráfego enquanto o usuário está acessando determinado serviço. Por
exemplo,
> quanto você consome de tráfego ou qual o total em Megabytes você precisa
> para acessar a Home de notícias do UOL ou qualquer outro site? Pode ser
que
> vc utilize 10MB, mas se você der um refresh na página esse número pode
> aumentar ou diminuir muito. E essa aleatoriedade ocorre pela combinação de
> diferentes fatores como os que eu mencionei acima.
>
>
> O que também acontece com água, luz e gás, quanto eu gasto de luz pra
fazer
> meu miojo? Sei lá!
>
>
> Mesmo para profissionais de tecnologia é muito difícil mensurar de forma
> precisa esses dados. Imagine então para um usuário leigo.
> Já é muito difícil entender coisas exatas, imagine entender coisas
> aleatórias. Com quais argumentos você vai explicar discutir com seu
cliente
> quando o mesmo contestar uma fatura? (isso é, se você irá fornecer fatura
> de consumo)
>
>
> Da mesma forma que contexto com a as companhia de gás, água e luz. Entendo
> que não haja equipamentos ditos certificados para medição de bits
> tranferidos, mas isso é praticável. Para dados móvel,  por exemplo, hoje
já
> há alternativa para isso, é possível bater o cobrado versus o consumido.
>
>
> Outro exemplo: Imagine um determinado dia que você teve problemas na sua
> rede que causou grande congestionamento e perda de pacotes. Então o
cliente
> no final do mês percebe que houve um aumento repentino de 30% no consumo.
> Você vai cobrar isso do cliente? E como você vai ter certeza se esse
> aumento foi realmente provocado por um problema na sua rede ou se foi o
> próprio cliente?
>
>
> Já vimos isso acontecer com água e luz também, lembra do caso da água com
> ar? Então cabe contestação e averiguação. Concordo que isso coloca
> complexidade o que pode burocrática o processo, mas seria o preço para
esse
> método.
>
>
> Infelizmente tráfego de dados não é como um cano de água que você pode
> colocar um higrômetro. E mesmo que você meça o trafego, haverão
> divergências se forem medidos em lugares diferentes da rede. E além dessa
> questão diferença da medição ainda existe a falta de linearidade entre o
> que é trafegado e o que realmente é consumido pelo cliente.
>
>
> O modelo adequando me parece ser tráfego total trafegado, overhead não
> acredito ser possível calcular. Quanto a seu exemplo do cano, acredito ser
> exatamente assim, se há desvio antes ou depois é uma questão de definir a
> melhor solução.
>
>
> Se alguém me apresentar soluções para esses problemas, talvez eu reveja
> minha opinião. Mas por enquanto prefiro manter minha oposição a respeito
> desse da implantação de franquia de dados.
>
>
> Não vejo grandes desafios técnicos, apenas uma complexidade que hoje possa
> não existir, porisso defendo que ter ou não franquia, faça parte do
> produto.
>
>
>
>
>
> On Sat, 21 Jan 2017 at 18:36 Flavio Rescia Dias <
> flavioresciadias at gmail.com>
> wrote:
>
> > Eu sou um cliente preguiçoso e para mim pagar para receber 100% de
> > utilização possível por 100% está ótimo, então como consumidor acho ruim
> e
> > se uma operadora oferecer um plano "ilimitado" eu vou preferir.
> >
> > Se hoje eu pagasse R$100 por um link de 1bps eu conseguiria
> > consumir 2592000bits/mês, se me oferecerem um plano com franquia de
> > 2592000bits/mês será o mesmo que a atual "franquia ilimitada".
> >
> > Mas se a operadora oferecer um plano com franquia de transferência em
> bytes
> > igual a metade, me cobrando metade do valor ou um pouco a mais, seria um
> > bom negócio. Afinal eu não uso meu link 100% do tempo. Porém a maioria
> das
> > operadoras oferece serviços ruins, não tem credibilidade e devem usar
> esse
> > mudança para ganhar mais dinheiro. No meu exemplo da CavernaNet eu
> poderia
> > pagar R$50 por 2592000bits/mês. Se tentassem me enganar eu procuraria
> > outra, se não tivesse opção, como hoje muitos não tem eu contrataria o
> > melhor dentro das possibilidades.
> >
> > Li todo o fluxo da discussão e o que conclui foi:
> >
> >    - Pessoas estão pensando como o cliente preguiçoso que eu sou e com
> medo
> >    das operadoras tirarem vantagem da situação;
> >    - Essas pessoas estão discutindo com sócios e colaboradores de
> >    provedores que NÃO tratam os clientes como a maioria das operadoras;
> >    - O Brasil é uma bagunça fiscal e deveria mudar muitas coisas;
> >    - O Brasil tem um governo que usa mal seu dinheiro, quando não
> distribui
> >    entre os membros do próprio governo;
> >    - Nenhum das minhas conclusões muda a minha opinião de que o mercado
e
> >    os fornecedores com seus produtos é que devem regular preços;
> >
> >
> > Flávio Rescia Dias
> >
> > Em 20 de janeiro de 2017 17:47, Marcelo Terres <mhterres at gmail.com>
> > escreveu:
> >
> > > Eh, eh soh mais uma tecnica do governo para receber mais impostos
> > > disfarcando o nome.
> > >
> > > Significado de Contribuição
> > >
> > > s.f.Ato ou efeito de contribuir.
> > > Parte que toca a cada pessoa numa despesa comum.
> > >
> > >
> > > Pagamento devido por cada cidadão ao Estado ou à municipalidade;
> tributo.
> > >
> > > Nao precisa dizer mais nada...
> > > Marcelo H. Terres <mhterres at gmail.com>
> > > IM: mhterres at jabber.mundoopensource.com.br
> > > https://www.mundoopensource.com.br
> > > https://twitter.com/mhterres
> > > https://linkedin.com/in/marceloterres
> > >
> > >
> > > 2017-01-18 14:31 GMT+00:00 Fred Pedrisa <pedrisa at hyperfilter.com>:
> > > > São contribuições que somos "obrigados" a pagar, através de
> > "imposição",
> > > não
> > > > é algo opcional. Portanto, pode ser sim chamado de imposto !
> > > >
> > > >
> > > >
> > > > On 18/01/2017 12:20, Bruno Cabral wrote:
> > > >>
> > > >> PIS COFINS CSLL são contribuições, não impostos, e as alíquotas são
> > > >> substancialmente menores que o ICMS que varia entre 25 e 42% da
> tarifa
> > > >>
> > > >> IRPJ existem mil maneiras de pagar pouco.
> > > >>
> > > >> !3runo
> > > >>
> > > >> ________________________________
> > > >> De: gter <gter-bounces at eng.registro.br> em nome de Leandro Carlos
> > > >> Rodrigues <leandro at allchemistry.com.br>
> > > >> Enviado: quarta-feira, 18 de janeiro de 2017 12:03:02
> > > >> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> > > >> Assunto: Re: [GTER] RES: RES: RES: Petição para Internet sem Limite
> de
> > > >> Trafego.
> > > >>
> > > >> Em 18/01/2017 11:45, Rubens Kuhl escreveu:
> > > >>>>
> > > >>>> O imposto que incide em Telecom é o ICMS, que é estadual, o
> governo
> > > >>>> federal não tem aumento de arrecadação com essa medida
> > > >>>>
> > > >>> PIS, COFINS, CSLL e IRPJ são federais.
> > > >>
> > > >> Interessante como nossos impostos são tão "camuflados", que muitos
> > > >> cidadãos não se dão conta a proporção de impostos dentro de um
> produto
> > > >> ou serviço. A primeira vista é simples mas, se destrinchar, vai ver
> o
> > > >> real emaranhado medonho desse sistema.
> > > >>
> > > >> Segue um vídeo muito interessante sobre simplificação tributária,
> que
> > > >> assisti esses dias:
> > > >>
> > > >>      https://www.youtube.com/watch?v=CPg1JYiRGmo
> > > >>
> > > >> Minha opinião é que produtos serviços considerados essenciais, pelo
> > > >> próprio governo, deveriam ser imunes a qualquer tipo de imposto,
> seja
> > > >> federal, estatual ou municipal, mesmo aqueles pela renda.
> > > >>
> > > >> Tributar aquilo que é considerado um direito é uma das maiores
> > > >> contradições lógicas que eu já vi na vida.
> > > >> --
> > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >> --
> > > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > >
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
--
gter list    https://eng.registro.br/mailman/listinfo/gter