[GTER] qos

[Shine]

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
>