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

Tue Jan 24 19:09:03 -02 2017

Flávio Rescia Dias

Em 24 de janeiro de 2017 10:39, Israel Ramos <israel.melo.ramos at gmail.com>
escreveu:

> 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.
>

Bastaria adquirir 100% do trafego possível por 100% do tempo. Eu preferiria
escolher.

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

Isso acontece comigo todo mês d-;

>
> 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.
>

Isso já acontece hoje, compro 10Mbps e levo 8Mbps de dados útil trafego, as
vezes menos conforme você mesmo explicou.

>
> 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).
>

Você supõe que devemos pagar pelos dados úteis transferido, eu acredito que
o overhead faça parte o serviço, se você usa SSL e o outro não seu total
trafegado será maior. Mas veja, isso vale para os 2 modelos, como disse no
e-mail anterior, utopia é imaginar que essa overhead não custa para
operadora e que hoje você já não pagar por ele.

>
> 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.
>

Sim, mas certamente na passado o mesmo foi pensado quanto a água, luz,
telefone, etc.

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