[GTER] Traffic Engineering

[Loureiro, Rodrigo]

Olá Roosevelt,

Concordo com essa definição se e somente se considerarmos que, após uma
tomada de decisão de engenharia de tráfego, não existirá congestão em nenhum
nó na rede. Entretanto, imagine, por exemplo, que eu implemente um mecanismo
de marcação na entrada da rede (ex: two rate three color), na qual o tráfego
não-conforme proveniente do cliente seja marcado de vermelho e, portanto,
tendo prioridade de discarte num ponto de congestão. Imagine agora que eu
decida tomar uma decisão de engenharia de tráfego na qual, após essa tomada
de decisão, haverá um ponto de congestão na rede, mas somente tráfego
não-conforme será discartado. Do ponto-de-vista conceitual, os dois tópicos
continuam independentes. Entretanto, do ponto-de-vista prático, uma
implementação depende da outra; ou seja, se a infra-estrutura não for capaz
de tomar uma decisão na velocidade da linha, poderá ser descartado tráfego
conforme ao invés de não-conforme, o que tornaria a tomada de decisão de
engenharia de tráfego incoerente.

--
R.


-----Original Message-----
From: Roosevelt Ferreira [mailto:roosevel at juniper.net]
Sent: Tuesday, May 07, 2002 1:09 PM
To: gter at eng.registro.br
Subject: RE: [GTER] Traffic Engineering


Para colocar meu dois centavos de real (emprestados!), vai uma "reflexão" do
Tony Li (Procket):

"TE is all about running the network at a higher average utilization while
maintaining the exact same supported traffic load.

Note that flow control and queueing are not the same as traffic engineering.
They are certainly congestion management techniques and we'd die quickly
without them. But they act to suppress the load on the network. That's not
the goal. The goal is to support the load. Not avoid it."

Quando falamos de "traffic load", estamos precisamente pensando em
"planejamento de tráfego", no mesmo sentido q aplicávamos o termo para as
redes de voz => "The goal is to support the load. Not avoid it."

Segue link para artigo completo:

MPLS Will Outgun ATM, Says Poll
http://www.lightreading.com/boards/message.asp?msg_id=32612


- Roosevelt

= = = = = = = = =

 >-----Original Message-----
 >From: Carlos Ribeiro [mailto:carribeiro at yahoo.com]
 >Sent: Monday, May 06, 2002 1:01 PM
 >To: gter at eng.registro.br
 >Cc: Loureiro, Rodrigo; Reinaldo Penno
 >Subject: Re: [GTER] Traffic Engineering
 >
 >
 >On Mon 06 May 2002 12:08, you wrote:
 >> Carlos, da próxima vez responderei em offline.
 >
 >Rodrigo, 
 >
 >Acho que não há necessidade disso. Flames à parte, a 
 >discussão enriquece a 
 >todos no grupo.
 >
 >De certa forma, concordo com o que o Reinaldo disse (mesmo 
 >que ele também 
 >seja do time dos fornecedores :-) Gostaria de colocar tudo sob uma 
 >perspectiva mais ampla; a idéia não é defender um ou outro 
 >fornecedor ou 
 >tecnologia, mas fazer uma avaliação bastante fria e realista.
 >
 >O tema 'Traffic Engineering', e a própria forma como estamos 
 >discutindo aqui 
 >no grupo, ilustra uma diferença muito grande de perspectiva entre os 
 >fornecedores de tecnologia (Unisphere, Nortel, e todos os 
 >outros...) e os 
 >verdadeiros usuários dessa tecnologia, dos quais temos vários 
 >representantes 
 >presentes na lista. Em meio a tanto 'hype', muitas vezes fica 
 >difícil para 
 >nós (potenciais clientes) distinguir o que realmente importa 
 >daquilo é puro 
 >marketing. Somente a discussão aberta, isenta de conceitos 
 >pré-formatados, 
 >vai nos permitir atingir a profundidade adequada ao tema.
 >
 >Sobre a sua resposta original: todos os pontos que você levantou são 
 >importantes, especialmente se deixarmos de pensar em técnicas 
 >específicas - 
 >que são as soluções - para pensar nos requisitos técnicos e 
 >operacionais. 
 >Para cada problema, há várias soluções possíveis, umas 
 >melhores do que 
 >outras, mas cada uma com seus pontos fortes e fracos. No 
 >entanto, ANTES de 
 >chegarmos a uma arquitetura non-blocking, wire-speed, 'onisciente' e 
 >'onipresente', é preciso que seja feito o trabalho básico de 
 >PLANEJAMENTO DE 
 >TRÁFEGO. É ele quem nos diz se precisamos de baixa latência, 
 >ou se uma espera 
 >a mais não vai fazer mal nenhum... 
 >
 >Assim, de volta ao tema... acho que é importante discutirmos 
 >o que é a 
 >engenharia de tráfego, independente do equipamento ou da arquitetura 
 >específica de cada operadora. Qualquer que seja a tecnologia, 
 >o tráfego 
 >estará lá, e precisamos aprender muito sobre ele ainda. 
 >Espero que possamos 
 >utilizar este grupo - que tem horas de vôo suficientes para 
 >pilotar um 
 >monomotor até Júpiter - para elevar o nível da discussão 
 >técnica aqui na 
 >terrinha.
 >
 >Espero que essas palavras sejam bem recebidas, e que não 
 >estejamos começando 
 >uma nova 'flame war', que ao final só consegue dividir e 
 >esvaziar o grupo.
 >
 >
 >Carlos Ribeiro
 >CTBC Telecom
 >--
 >GTER list    http://eng.registro.br/mailman/listinfo/gter
 >
--
GTER list    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.