[GTER] qos

[Julio Arruda]

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