[GTER] Traffic Engineering

Mon May 6 12:09:00 -03 2002

Reinaldo,

Acredito realmente que o primeiro passo em direção a uma rede convergente
seja ter uma infra-estrutura capaz de acomodar o pior caso, seja esse voz,
vídeo etc. 

Lembro-me da sua palestra sobre traffic engineering, onde você sugeria
atualizar os drivers TCP dos hosts da rede , a fim de otiimzar o consumo de
banda. Não preciso dizer que não concordo com esse ponto-de-vista, e que ele
é completamente inviável para um provedor de serviço, no entanto respeito-o.

Carlos, da próxima vez responderei em offline.

--
Rodrigo

-----Original Message-----
From: Reinaldo Penno [mailto:reinaldo_penno at nortelnetworks.com]
Sent: Monday, May 06, 2002 7:37 AM
To: gter at eng.registro.br
Subject: RE: [GTER] Traffic Engineering

>-----Original Message----- 
>From: Loureiro, Rodrigo [ mailto:RLoureiro at unispherenetworks.com
<mailto:RLoureiro at unispherenetworks.com> ] 
>Sent: Monday, May 06, 2002 7:27 AM 
>To: 'gter at eng.registro.br' 
>Subject: RE: [GTER] Traffic Engineering 
> 
> 
>Carlos, 
> 
>Acho que o problema começa antes disso. Primeiramente você 
>precisa ter uma 
>infra-estrutura IP capaz de atender as condições de contorno de sua 
>aplicação (ex: baixa latência). Existem diversos pré-requisitos 
>arquiteturais para se conseguir isso, como arquitetura 
>distribuída baseada 
>em hardware (ASICs, FPGAs), implementação de filas em hardware 
>por usuário, 
>wire-speed, capacidade de coletar estatísitcas granulares em 
>wire-speed sem 
>afetar a performance do equipamento... 

papo de vendedor...vamos ver se no proximo email vc da argumentos mais
convincentes. 

Imagine que exista uma 
>política de 
>QoS implementada no backbone, de forma a dar preferência a aplicações 
>críticas. E,num determinado instante de tempo, experimentou-se 
>congestão num 
>nó da rede. Se esse nó da rede não conseguir diferenciar 
>tráfego tão rápido 
>quanto a velocidade da linha, certamente os pacotes da 
>aplicação crítica 
>serão discartados, mesmo que a quantidade de tráfego crítico 
>seja menor do 
>que a banda disponível no tronco congestionado. 
> 
>Enfim, concordo que convergir diferentes tecnologias numa mesma 
>infra-estrutura seja complicado num primeiro momento, principalmente no 
>tocante à capacity-planning, engenharia de tráfego... 
>Entretanto, existe 
>solução estável para todos os pontos levantados abaixo e, uma 
>vez feito da 
>forma correta e endereçando todos as condições de contorno 
>relevantes, a 
>operação fica bastante otimizada. 
> 
> 
>-- 
>Rodrigo 
> 
> 
> 
>-----Original Message----- 
>From: Carlos Ribeiro [ mailto:carribeiro at yahoo.com
<mailto:carribeiro at yahoo.com> ] 
>Sent: Friday, May 03, 2002 2:38 PM 
>To: gter at eng.registro.br 
>Subject: Re: [GTER] Traffic Engineering 
> 
> 
>On Fri 03 May 2002 15:55, you wrote: 
>> Enfim, já existe tecnologia capaz de fazer grande uso dos 
>conceitos de 
>> traffic engineering. 
> 
>Rodrigo, 
> 
>Certamente que a tecnologia existe... RSVP-TE, CR-LDP e toda 
>uma sopa de 
>letrinhas para estabelecer túneis 'automagicamente' dentro uma 
>rede MPLS. No 
> 
>entanto, não foi esse o ponto que eu estava levantando. 
> 
>Para tirar proveito dessas ferramentas, é necessário que seja feito um 
>trabalho sério de dimensionamento e de engenharia de tráfego. 
>Por exemplo: 
>em 
>uma rede de voz tradicional, existe o modelo de Erlang, onde 
>todo interesse 
>de tráfego é considerado. O resultado final indica o 
>dimensionamento correto 
> 
>dos troncos entre as centrais para carregar o tráfego especificado. 
> 
>Agora, vamos fazer tudo sobre IP, com MPLS e RSVP-TE. Qual 
>será a banda 
>necessária em cada tronco? Se a única aplicação na rede for 
>voz-sobre-IP, 
>então o modelo de Erlang se aplica, pelo menos no sentido de 
>prever quantas 
>conversações simultâneas precisam ser suportadas no mesmo 
>link. Em princípio 
> 
>(há controvérsias a respeito disso), bastaria converter o 
>número de canais 
>em 
>volume de banda, usando para isso os parâmetros de 
>dimensionamento do canal 
>emulado com voz sobre IP (incluindo overhead, etc.). 
> 
>Agora, vejamos as diferenças de se fazer isso sobre uma rede IP/MPLS. 
> 
>1) Suponhamos que um determinado roteador 'caia'. O tráfego de 
>voz deve ser 
>reroteado por outro caminho. No caso da central de voz, 
>existem conceitos 
>como rota alternativa e rota de transbordo, que permitem ao 
>engenheiro de 
>tráfego especificar, de antemão, qual será a política de 
>roteamento em caso 
>de problemas. Estas rotas (alternativa e transbordo) também 
>seguem políticas 
> 
>bem definidas, e são dimensionadas de acordo com os estudos de 
>engenharia de 
> 
>tráfego. Assim, a operadora sabe que, se uma rota 'cai', a 
>rota de reserva 
>tem capacidade para suportar o tráfego adicional. 
> 
>No caso da rede IP/MPLS, a escolha da rota alternativa depende 
>em grande 
>medida do IGP utilizado (OSPF-TE ou MP-BGP, por exemplo), e 
>dos pesos usados 
> 
>para cada uma das rotas. No entanto, qualquer um que já tenha tentado 
>configurar sistemas de roteamento IP dinâmico sabe o quanto é 
>difícil prever 
> 
>exatamente o que vai ocorrer em cada cenário; mais difícil 
>ainda é acertar 
>os 
>pesos de tal forma que você consiga prever o que acontece em 
>*qualquer* 
>cenário. Uma pequena mexida em um ajuste local, e a 
>convergência da rede 
>para 
>outros casos também é afetada. Assim, é fácil que uma decisão de 
>reroteamento 
>faça com que o tráfego, que antes cabia no tronco principal, 
>sature o tronco 
> 
>reserva. 
> 
>2) Por enquanto, era só voz... agora, coloque no mesmo tronco 
>voz, dados, 
>etc. Neste momento, ainda não há modelos adequados para prever 
>o que é que 
>pode acontecer quando houver uma falha. O resultado vai 
>depender do bom 
>senso, da experiência (e sorte) do engenheiro responsável pelo 
>roteamento 
>IP. 
> 
>Felizmente (ou infelizmente?) o problema ainda não é sério, 
>porque ainda é 
>mais barato superdimensionar os troncos de dados do que fazer um bom 
>trabalho 
>de engenharia de tráfego. No entanto, por mais que desejemos 
>que seja assim, 
> 
>isso não deve permanecer para sempre... Mesmo hoje, com um 
>cenário econômico 
> 
>recessivo, falar em superdimensionamento é tabu. 
> 
> 
>Em resumo: Traffic Engineering não se resolve só com uma 
>tecnologia, ou com 
>um protocolo, por melhores que sejam. É necessário desenvolver 
>modelos, 
>práticas, e principalmente, cultura para que isso seja 
>possível. A não ser, 
>é 
>claro, que continue sendo mais barato superdimensionar os troncos... 
> 
> 
>Carlos Ribeiro 
>CTBC Telecom 
>-- 
>GTER list    http://eng.registro.br/mailman/listinfo/gter
<http://eng.registro.br/mailman/listinfo/gter>  
> 
>======================================= 
>This email message is for the sole use of the intended 
>recipient (s) and may 
>contain confidential and privileged information, including without 
>limitation, Confidential and/or Proprietary Information belonging to 
>Unisphere Networks, Inc. Any unauthorized review, use, disclosure or 
>distribution is prohibited. If you are not the intended 
>recipient, please 
>contact the sender by reply email and destroy all copies of 
>the original 
>message. 
>-- 
>GTER list    http://eng.registro.br/mailman/listinfo/gter
<http://eng.registro.br/mailman/listinfo/gter>  
> 

======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eng.registro.br/pipermail/gter/attachments/20020506/4e5ad203/attachment.html>