[GTER] qos

Sun Jul 1 14:53:19 -03 2007

-----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?
>>>>>>
>>>>>>
>>>>>> []s,
>>>>>>
>>>> --
>>>> 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
> 

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

iD8DBQFGh+oPdv+yGU7+Um0RAhZ7AJ4z4QMyb7CyWhOucq3s11mXBlsxqwCeLXaC
E/H8uWEuKHHJX/++zORr4BQ=
=Ic/x
-----END PGP SIGNATURE-----