[GTER] Overhead Link Dedicado

Tue Jan 29 22:27:24 -02 2019

Posso estar falando besteira, mas vocês estão considerando overhead de qual(is) camada(s)/protocolo(s)? O fato de ser um link IP, e não algum serviço Ethernet, não deveria descartar overhead de cabeçalhos camada 2 no controle de banda?

Para ter 4% de overhead (400Mbps em um total de 10.000Mbps) descontado da banda, não deve ser só overhead do protocolo IP, que é só 1,3% de um MTU de 1500B.

No meu ver, ele deveria estar recebendo 10Gbps de banda IP, fora o overhead Ethernet. Se a porta 10GbE não entrega isso por causa do overhead Ethernet, tem que trocar por uma porta com mais capacidade. Porta 10GbE não entrega 10Gbps de banda IP.

E mais: o fornecedor vender 10Gbps IP e ver a porta consumindo mais que isso por causa do overhead Ethernet não é problema nem pra ele, já que Ethernet fica dentro da rede, não sai para os upstreams IP dele. Considerar que 9.6Gbps é normal para quem contrata 10Gbps IP é aceitar o cara pagar por 270Mbps (os outros 130Mbps desses 400Mbps são overhead IP) que nem é banda IP.

---- On Tue, 29 Jan 2019 18:29:35 -0200 fhfrediani at gmail.com wrote ----

On 29/01/2019 18:03, Bruno Souto wrote:
> e a grande questão, se eu contratar 9.5Gbps ela me entraga sem contabilizar
> o overhead,
> agora se contrato 10Gbps o overhead entra na conta.

Como é possível certificar-se dessa informação que em um caso é sem 
overhead e na outra é com ? Como isso foi medido ? Essa informação esta 
no mínimo estranha ou carece de verificação.

Na prática é impossível não haver o overhead para haver Internet então 
ele faz parte de todos os cenários além de ter que ser igualmente 
transportado igualmente ao payload por qualquer fornecedor.
E no caso dos uplinks que suportam Jumbo Frame e portanto diferentes e 
uma maior variedade de tamanhos de MTU passando como fazer para 
descontar o overhead. Não faz sentido.

Fernando

>
>
>
>
> Em ter, 29 de jan de 2019 às 17:28, Guilherme de Freitas Figueiredo <
> guilhermefreitasfigueiredo at gmail.com> escreveu:
>
>> Acho que a questão não é essa. Seu cliente dedicado ele compra 10Mbps com
>> ou sem overhead? É nessa questão que acho que o Bruno está querendo entrar.
>> Se seu cliente te questionar que a banda dele está dando somente 9.8Mbps e
>> não os 10Mbps conforme contratado, vamos ter que explicar pra ele que esses
>> 0.2Mbps são de overhead? Isso levando em conta um link de 10Mbps.
>>
>> Hoje nós vendemos links dedicados, banda larga, sem levar em conta o
>> overhead que temos. Eu penso que sim, se eu vendo 10Mbps,20,50 ou 200Mbps
>> para o meu cliente o calculo é feito sem overhead e se eu compro isso da
>> operadora também deveria ser, ja discuti isso com alguns colegas que hoje é
>> melhor você comprar 9.5Gbps ou 11Gbps do que 10Gbps conforme o Rodrigo
>> informou na ultima mensagem.
>>
>> Abraços!
>>
>> []s!
>>
>> --
>> Guilherme de Freitas Figueiredo
>>
>>
>> On Tue, Jan 29, 2019 at 4:30 PM Rodrigo Pedrosa <rodrigopa.uepb at gmail.com>
>> wrote:
>>
>>> Desculpe a intromissão, mas o intuito é contribuir com o colega. O link
>>> está saturado? Caso esteja, poderia fazer um pequeno upgrade que
>> resolveria
>>> essa questão (teria que ver a viabilidade e prazo antes também com a
>>> operadora), não poderão entregar na porta de 10G, devem agregar outra
>> porta
>>> ou subir numa de 40G.
>>> Caso esteja com sobra é mais complicado, tem que ver a questão
>> contratual,
>>> inclusive se o contrato permite downgrade, mas pode tentar negociar.
>>> Um detalhe a ser lembrado é que caso seja feito um upgrade, será feito um
>>> aditivo no contrato ou gerado um novo contrato, e precisa verificar a
>>> questão de fidelidade contratual, que normalmente é renovado o prazo.
>>> Atenciosamente, Rodrigo Pedrosa de Aguiar
>>>
>>> Em ter, 29 de jan de 2019 às 14:32, Fernando Frediani <
>>> fhfrediani at gmail.com>
>>> escreveu:
>>>
>>>> Mas eles não estão entregando os 10Gb ? Na minha visão estão. Ou a
>>>> expectativa é que seria entregue sem o overhead que faz parte da
>>>> tecnologia. Eu particularmente nunca vi isso.
>>>>
>>>> Além disso quem gera boa parte desse overhead é você mesmo ou seus
>>>> clientes então se for pegar nisso a operadora poderia hipoteticamente
>>>> dizer que você esta fazendo isso de maneira ineficiente utilizando MTU
>>>> 1500. E ai ?
>>>>
>>>> Fernando
>>>>
>>>> On 29/01/2019 11:14, Bruno Souto wrote:
>>>>> Mário exatamente nesse ponto queria chegar.
>>>>> Eu comprei um link de 10Gbps e não uma porta de 10GE
>>>>>
>>>>> se fosse a porta de 10GE não tinha o que discutir, pois estaria
>>> correto.
>>>>> agora eu comprei foi um Link IP Dedicado de 10Gbps, e na fatura está
>>>> sendo
>>>>> cobrado 1000M
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Em ter, 29 de jan de 2019 às 05:51, Mário Sapucaia Neto <
>>>>> mariosapucaia at gmail.com> escreveu:
>>>>>
>>>>>> Bom dia!
>>>>>>
>>>>>> Mas as semi-carriers, como falava nosso amigo Bogus, vendiam sempre,
>>>> Fast
>>>>>> 90M, Gig 900M, então seguindo a matemática... Isso foi motivo de
>>>>>> controvérsia em 2011... O Bruno comprou uma porta 10Gbe ou um Link
>> 10
>>>>>> GIGA????
>>>>>>
>>>>>> Em seg, 28 de jan de 2019 às 17:02, Fernando Frediani <
>>>>>> fhfrediani at gmail.com>
>>>>>> escreveu:
>>>>>>
>>>>>>> Acredito que o mais importante no momento diante de um cenário
>> aonde
>>> a
>>>>>>> maioria dos Links Dedicados (em alguns casos até mesmo em portas de
>>>>>>> 10Gb) ainda não são ativados com suporte à Jumbo Frame, seria se
>>>>>>> concentrar nisso como também em garantir que os backbones possuam
>>>>>>> suporte completo.
>>>>>>>
>>>>>>> Feito isso já será possível utilizar de imediato Jumbo Frame para
>> uso
>>>> em
>>>>>>> aplicações específicas o que seria uma vantagem e estímulo para
>>>> cenários
>>>>>>> que hoje sequer são considerados para então passar para a discussão
>>>>>>> sobre a análise e o avanço desse suporte até o usuário final atrás
>> de
>>>>>> CPE.
>>>>>>> Abraços
>>>>>>> Fernando Frediani
>>>>>>>
>>>>>>> On 28/01/2019 08:12, T. Ayub wrote:
>>>>>>>> Olá Frediani,
>>>>>>>>
>>>>>>>>
>>>>>>>> Esse é o mesmo raciocínio que muita gente usa para não adotar
>> IPv6,
>>> o
>>>>>>> que é
>>>>>>>> prejudicial em ambos os casos.
>>>>>>>>
>>>>>>>> "Ah, foi sempre assim não vale a pena mudar."
>>>>>>>>
>>>>>>>> Vale a pena sim senhor.
>>>>>>>>
>>>>>>>>
>>>>>>>> Abraços,
>>>>>>>>
>>>>>>>>
>>>>>>>> Ayub
>>>>>>>>
>>>>>>>> Em dom, 27 de jan de 2019 13:09, Fernando Frediani <
>>>>>> fhfrediani at gmail.com
>>>>>>>> escreveu:
>>>>>>>>
>>>>>>>>> Pois é, são tantos "ses" que na prática não adianta muito e não
>>>> haverá
>>>>>>>>> nenhum ganho significativo se o tráfego for majoritariamente de
>>>>>>> clientes de
>>>>>>>>> banda larga portsbto a perda devido ao overhead faz parte desse
>>> tipo
>>>>>> de
>>>>>>>>> cenário.
>>>>>>>>>
>>>>>>>>> Fernando
>>>>>>>>>
>>>>>>>>> On Sun, 27 Jan 2019, 12:49 Douglas Fischer <
>>> fischerdouglas at gmail.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> @Fernando
>>>>>>>>>> Informação parcialmente inverdadeira!
>>>>>>>>>>
>>>>>>>>>> Se:
>>>>>>>>>> a- Todo o caminho da rede, incluindo CPEs dos seus clientes e a
>>> Lan
>>>>>>>>> deles,
>>>>>>>>>> incluindo o caminho até os servidores de conteúdo, tiverem
>> suporte
>>>>>>>>> correto
>>>>>>>>>> ao Jumbo-Frame L2 e L3.
>>>>>>>>>> b- Os usuários utilizarem sistemas operacionais razoavelmente
>>>>>> recentes
>>>>>>>>> (To
>>>>>>>>>> falando de Android 5 para cá, e Windows 8 para cá.)
>>>>>>>>>> c- Não tiver um "Faireuól" configurado por leitor de
>>>>>>>>>> viva-o-linux(praticante de obscuridade) no meio do caminho, e os
>>>>>>> pacotes
>>>>>>>>>> ICMP conseguirem ir e voltar corretamente do Client para o
>> Server.
>>>>>>>>>> c.1- Não tô falando só de ping! To falando de Path MTU
>>>> Discovery
>>>>>>>>>> Mesmo que o MTU Default dos sistemas operacionais seja 1500,
>> eles
>>>> vão
>>>>>>>>>> conseguir negociar um MTU mais alto, e o JumboFrame (ou Baby
>>> Jumbo)
>>>>>> vai
>>>>>>>>>> funcionar.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> P.S.: @Bruno, peço desculpas por me apossar da thread.
>>>>>>>>>>
>>>>>>>>>> Em qua, 23 de jan de 2019 às 14:02, Fernando Frediani <
>>>>>>>>>> fhfrediani at gmail.com>
>>>>>>>>>> escreveu:
>>>>>>>>>>
>>>>>>>>>>> Se está vatendo ~9600 Mbps então ela está entregando os 10Gb
>>>>>>> justamente
>>>>>>>>>>> pelo motivo que você colocou no Subject da mensagem, o
>> Overhead.
>>>>>>>>>>> Com MTU a 1500 é dificil ter algo além disso.
>>>>>>>>>>>
>>>>>>>>>>> Usando Jumbo Frame sobretudo se o MTU for 9000 ou próximo disso
>>>>>> seria
>>>>>>>>>>> possível atingir uma velocidade mais próxima do limite da porta
>>> mas
>>>>>> o
>>>>>>>>>> ponto
>>>>>>>>>>> é que mesmo que suas portas de uplink e seu backbone
>> suportassem
>>>>>> Jumbo
>>>>>>>>>>> Frame os usuários continuam com MTU em 1500 então não iria
>> fazer
>>>>>>>>>> diferença
>>>>>>>>>>> significativa.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, 23 Jan 2019, 13:15 Bruno Souto <soutobruno31 at gmail.com
>>>>>> wrote:
>>>>>>>>>>>> Bom dia Senhores,
>>>>>>>>>>>> estou com uma dúvida, gostaria da opinião de vocês.
>>>>>>>>>>>>
>>>>>>>>>>>> Contrato um Link de 10Gbps, a operadora me entrega em uma
>> única
>>>>>>>>>> interface
>>>>>>>>>>>> SFP+
>>>>>>>>>>>> Então percebo que o link chega no máximo 9600 Mbps.
>>>>>>>>>>>>
>>>>>>>>>>>> Porem no Contrato pago 10.000 Mbps.
>>>>>>>>>>>> Parece pouco, mas dá para comprar um carro de 50 mil por ano!
>>>> rsrs
>>>>>>>>>>>> então pergunto aos senhores, não deveria entregar os 10.000
>>> Mbps ?
>>>>>>>>>>>> A operadora informa que está entregando os 10Gbps
>>>>>>>>>>>> --
>>>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> gter list https://eng.registro.br/mailman/listinfo/gter
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Douglas Fernando Fischer
>>>>>>>>>> Engº de Controle e Automação
>>>>>>>>>> --
>>>>>>>>>> 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
--
gter list https://eng.registro.br/mailman/listinfo/gter