[GTER] qos

Sun Jul 1 18:18:55 -03 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Acho q depende muito da arquitetura do provedor. Se vc tem possibilidade
de usar QinQ, não há necessidade de remarcar o tráfego do Q interno, vc
pode manipular à vontade essas informações e devolver o pacote do outro
lado intacto.
No fundo a classificação não tem o menor sentido se não houver algo q
interprete isso no caminho, portanto na prática para um provedor é
melhor desprezar isso qdo lhe for conveniente e passar exatamente como
está para evitar maiores dores de cabeça.

sd,
Edgar

Julio Arruda escreveu:
> 
> A titulo de curiosidade, algum provedor de transito "remarca" trafego 
> para Best Effort (ou 'toca' de qualquer forma o DSCP ?)
> Eu conversei com um sujeito da Qwest, outro da Cogent, que dizem que nao 
> fazem isto, mas sempre vejo pessoal dizendo que nao adianta marcar que o 
> provedor 'remarca'..La em casa, vejo trafego chegar marcado dos 
> provedores VOIP, mas poderia ser o meu universo que e' muito pequeno..
> 
> 
> Edgar Shine wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> É verdade... me confundi em algum ponto nas remarcações. :P
>>
>> Um outro ponto levantado é sobre a necessidade de ter marcações DSCP na
>> rede local. Na verdade o CoS não é tão relevante do ponto de vista de um
>> switching local, ao menos em ethernet a capacidade de switching tem
>> escalado de acordo com a demanda das aplicações. No entanto é comum ver
>> a separação de redes locais de um tamanho considerável em domínios de
>> broadcast distintos, e nesse caso, roteamento em redes locais são usados
>> frequentemente e faz sentido ter um controle de descarte e enfileiramento.
>>
>> sd,
>> Edgar
>>
>> Julio Arruda escreveu:
>>> Curioso..
>>>
>>> DiffServ nao e' o rei, nao importa aonde ?
>>> Eu venho de Bay/Nortel, e a enfase sempre foi em usar DiffServ mesmo na 
>>> lan, com uma 'fronteira' de acesso/core fazendo o remarking se 
>>> necessario, mas como o Edgar falou, dispositivos geralmente fazem 
>>> marking 'antes' de colocar no tubo
>>> (e eu diria mais, Edgar, os VOIP que eu vi, ja faziam o DSCP de cara, o 
>>> 802.1p nao, pois geralmente eles nao tinha 802.1Q habilitado, o que e' 
>>> necessario para o 802.1p, mesmo com null vlan tag ou algo assim, no 
>>> varejo de ATAs/IPphones para casa, isto e' bem mais comum no que eu vi)
>>>
>>> Shine wrote:
>>>> Concordo, mas 802.1p sem cópia para IP DSCP/PRI, ou MPLS Priority Bits não
>>>> adianta.
>>>> Os equipamentos VoIP em geral já mandam os pacotes marcados em EF no 802.1p,
>>>> mas isso não tem nenhum significado para IP. :)
>>>> Como corretamente citado pelo Adailton, os equipamentos do circuito LAN/WAN
>>>> têm q ter um PHB adequado para manipular esses pacotes, tanto em descarte
>>>> como enfileiramento. A LAN vc pode controlar, mas a WAN para a maioria é
>>>> terceirizada, então é necessário verificar se o SLA comporta o projeto e
>>>> montar as premissas da sua rede de forma a usar bem isso. Algumas operadoras
>>>> já ofertam redes com pacotes SLAs de QoS pré-moldados (ao menos vi isso em
>>>> algum folder da Telefonica em SP)
>>>> Para quem trabalha em operadoras, a técnica de network engineering não basta
>>>> no mundo competitivo e a tendência é partir para traffic engineering.
>>>>
>>>> sd,
>>>> Edgar
>>>>
>>>> Em 28/06/07, Adailton Silva <adailton at icomnet.com.br> escreveu:
>>>>> Melhor esforço é sempre sem melhor esforço. Na prática podem ocorrer
>>>>> situações na Lan que comprometam aplicações críticas. Pra isso foi
>>>>> desenvolvido o padrão IEEE 802.1p para a LAN.
>>>>>
>>>>> Ou seja, QoS bem feito tem que ser fim-a-fim: Classificação de tráfego,
>>>>> 802.1p na LAN e Diffserv na Wan, por exemplo.
>>>>>
>>>>> []s,
>>>>>
>>>>> Andre Gustavo de Carvalho Albuquerque wrote:
>>>>>> Edson,
>>>>>>
>>>>>> De uma forma geral, se as hardware queues não estiverem com ocupação
>>>>> acima
>>>>>> de um determinado patamar, os mecanismos de congestion management ou
>>>>>> congestion avoidance não são ativados.
>>>>>>
>>>>>> Se o perfil de aplicações e de tráfego, no caminho analisado, não força
>>>>> a hw
>>>>>> queue aos seus limites, ativar esses mecanismos (LLQ, CBWFQ, WRR, WRED,
>>>>> etc)
>>>>>> não causarão diferença.
>>>>>>
>>>>>> Introduza no seu cálculo as aplicações não desejadas. Diversos tipos de
>>>>>> worms já foram causa de parada de redes corporativas e a ameaça persiste
>>>>> pro
>>>>>> futuro.
>>>>>>
>>>>>> []s, Gustavo Albuquerque
>>>>>>
>>>>>>
>>>>>> On 6/28/07, Edson Moura <emoura10 at yahoo.com.br> wrote:
>>>>>>
>>>>>>> André,
>>>>>>>
>>>>>>> Numa situação em que a empresa faça vídeo-conferência com suas filiais,
>>>>>>> onde os Codec´s estão instalados num ponto qualquer da Lan, e
>>>>> sabendo-se que
>>>>>>> as outras aplicações são as triviais (web/Tftp/Download/ERP/etc,etc).
>>>>>>>
>>>>>>> Pode o acesso local destas aplicações comprometerem a
>>>>> vídeo-conferência,
>>>>>>> devido a ela precisar de baixar latência?
>>>>>>>
>>>>>>>
>>>>>>> abraço,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Andre Gustavo de Carvalho Albuquerque <gustavo.albuquerque at gmail.com>
>>>>>>> escreveu:
>>>>>>> Edson,
>>>>>>>
>>>>>>> Depende da aplicação. Para aplicações como voz e vídeo interativo, pode
>>>>>>> ser
>>>>>>> necessária a priorização em uma fila de prioridade para garantir baixa
>>>>>>> latência.
>>>>>>>
>>>>>>> Outro motivo é para proteger as aplicações mais críticas de ataques.
>>>>>>> Imagine
>>>>>>> um ambiente convergente numa LAN sujeito a um ataque interno (worm). A
>>>>>>> priorização pode fazer com que o tráfego devidamente classificado, como
>>>>> o
>>>>>>> de
>>>>>>> voz, não seja afetado.
>>>>>>>
>>>>>>> Veja essaa apresentações que contém informações interessantes:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> http://www.cisco.com/application/pdf/en/us/guest/tech/tk759/c1482/cdccont_0900aecd8019f3e0.pdf
>>>>> http://www.cisco.com/application/pdf/en/us/guest/products/ps6558/c1161/cdccont_0900aecd80312b59.pdf
>>>>>>> []s, Gustavo Albuquerque
>>>>>>>
>>>>>>>
>>>>>>> On 6/27/07, Edson Moura wrote:
>>>>>>>
>>>>>>>> Aproveitando o tema em questão, há necessidade de priorizar o tráfego
>>>>> na
>>>>>>>> Lan, sendo que o gargalo está sempre na WAN?
>>>>>>>>
>>>>>>>> Ou dependendo do tipo de tráfego/ou aplicação que rode dentro da Lan,
>>>>>>>>
>>>>>>> pode
>>>>>>>
>>>>>>>> afetar aplicação que precisam de maior prioridade?
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGiBo/dv+yGU7+Um0RAlS7AJ46/uGBkz6uhbdp5MCf5mQfPCKImgCfVDML
3UPRCluCfYHVboibejNrNiM=
=+Bzt
-----END PGP SIGNATURE-----