[GTER] qos

[Julio Arruda]

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?