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

Tue Jan 24 10:39:10 -02 2017

Flávio,

Os mecanismos que geram overhead são necessários para a entrega do serviço.
Esses mecanismos NÃO são uma opção para o cliente e sem tais mecanismos
você não pode entregar o serviço. Por que você acredita que esse tráfego de
dados adicional e variável gerado por esses mecanismos deveria ser
contabilizado e cobrados do cliente?
No modelo de precificação atual, a grande diferença está em que o cliente
sabe que independentemente do que aconteça durante aquele período de 30
dias, gerando mais ou menos overhead, ele não irá tomar um susto quando
receber a fatura (mesmo sem ter mudado seu perfil de consumo real). Já em
um modelo de cobrança por total de bytes ou pacotes trafegados essas
variáveis são imprevisíveis.

Falando agora como cliente, você gostaria de receber a fatura do cartão de
crédito sempre com um valor surpresa?

A maior parte dos fatores que influenciam diretamente na quantidade de
overhead não estão sob o controle do cliente e sim diretamente ligados as
circunstâncias de rede do fornecedor. E muitas vezes não estão nem ligados
a rede do fornecedor e sim por motivos fora dessas fronteiras, como por
exemplo um problema ou instabilidade na rede de outro ISP, fornecedor de
transito ou conteúdo. Por que diabos o cliente deveria ser onerado por
isso? Afirmar isso é a mesma coisa que dizer que o cliente sempre irá pagar
um valor inversamente proporcional a qualidade do serviço.

Este é o ponto que gostaria de evidenciar e justificar porque esse modelo
de cobrança, que apesar de funcionar muito bem para serviços de energia
elétrica e água, jamais funcionaria com isonomia para serviços de conexão
de dados. A menos que haja alguma maneira de driblar todos essas variáveis
e cobrar do cliente efetivamente o que ele consumiu, aquilo que
efetivamente foi exibido de forma plena na tela do cliente ou gravado em
disco. (parece até utopia imaginar que isso seria possível).

OBS.: Em relação ao equipamento para medição não pode ser no CPE ou ONU.
Isso por que não são equipamentos isentos de alteração. Deveria ser
equipamentos lacrados, homologados e sem qualquer tipo de acesso tanto pelo
fornecedor como pelo cliente. E nesse ponto estamos falando de adicionar um
maior custo na ativação, coisa que não é legal para os negócios de qualquer
ISP.

On Tue, 24 Jan 2017 at 09:52 Flavio Rescia Dias <flavioresciadias at gmail.com>
wrote:

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