[25673] in North American Network Operators' Group
Re: Traffic engineering tools
daemon@ATHENA.MIT.EDU (John Patteson)
Thu Oct 28 00:11:20 1999
Message-ID: <000f01bf20fa$6501e8c0$0100000a@gildenvaal>
From: "John Patteson" <johnp@mserv.sprintlink.net>
To: "Vadim Antonov" <avg@kotovnik.com>, <abender@tns-inc.com>,
<scharf@vix.com>
Cc: <nanog@merit.edu>
Date: Thu, 28 Oct 1999 00:10:38 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000C_01BF20D8.DD161560"
Errors-To: owner-nanog-outgoing@merit.edu
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01BF20D8.DD161560
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
----- Original Message -----=20
From: Vadim Antonov <avg@kotovnik.com>
To: <abender@tns-inc.com>; <scharf@vix.com>
Cc: <nanog@merit.edu>
Sent: Tuesday, October 26, 1999 5:05 PM
Subject: Re: Traffic engineering tools
> TE [snip] simply reallocates existing resources differently.
>
In reading your mail, I'm reminded of one of my favorite RFC's...
"The Twelve Networking Truths"
=20
(10) One size never fits all.
On the whole as a global solution, I would agree with you that different =
is not necessarilly better, and sub-optimal routing is not the best of =
solutions. There is an ISP we deal with who bounces their traffic around =
the network until it finds an available exit. All the exit points are =
nearly equally balanced, but the network as a whole is slow.
In some specific cases however (mostly peering), the peer's dynamic =
routing chooses what it believes to be the optimal exit path by choosing =
'closest gateway'/'nearest exit' routing. In these cases, sub-optimal =
utilization of your own external connections by the peer creates severe =
congestion/loss.=20
As an example I would present a peer with multiple connections to your =
network in topologically distributed locations (ie. opposite sides of =
your network). If the peer is utilizing one link in one direction at 80% =
and the other two at 10%, you need to make some adjustments in local =
pref, or redirect your outbound traffic destined for that peer (or his =
downstreams) to the peer's underutilized path(s). Otherwise you're going =
to have packets all over the floor at the link with 80% utilization. (!)
TE is necessary more often than most would care to admit, and occurs =
mostly at network borders, because none of the carriers/providers like =
having to pay for additional external connectivity any sooner than they =
absolutely _have_ to.
If you are a large provider with a large number of multiply-connected =
peers, traffic engineering (though rare) is a fact of life. Of course =
from an implementation standpoint Truth number 6 says:
(6) It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.
..aww, heck, from any standpoint.
> Note that customers do not generally care about bandwidth. =20
You didn't actually think I'd let this one slide, did you?
Next time _you_ can talk to the guy who's whining that his 1.544Mb T1 =
(ESF, AMI, B8ZS & TCP/IP) is only getting ~1.4Mb throughput (and of =
course, he's testing it with a web browser). After all, he's paying for =
bandwidth, and he's the customer, and the customer is always right. ;-)
> [the solution is] adequate provisioning and capacity planning=20
Which of course is the BEST way to handle most network problems, IF you =
have the money. ;-) Which brings me to the corollary to fundamental =
truth number 7:
Good, Fast, Cheap: Pick any two (you can't have all three).
> I strongly suspect that is because there are no real
> measurable benefits - and that TE is being used mostly to cover up
> planning problems and as a short-term fix to idiocies at a
> transmission level.
Of course there are benefits! They just don't have anything to do with =
the network. Why spend $1,000's on new pipes/routers when you can solve =
your problems for (almost) free by buying whatever will allow you to =
tweak your routing and 'optimize your utilization of existing =
resources'.
(I cut and pasted that from a certain vendor's marketing literature)
Vendor Marketing plays on your Management's fears. There's nothing that =
scares management more than justifying money spent, especially money =
spent for 'unneeded' resources. The fact that that shiny new gigabit =
pipe WILL eventually be fully utilized is immaterial. It's not being =
used NOW.
Small money is a small risk, and traffic engineering alleviates the =
problem at the problem point sufficiently to make it appear that it has =
gone away. It does this for minimal cost expenditure, which is an =
'optimal' solution where management is concerned.
Which brings me to my own personal addage:
You can troubleshoot layers 1-7,=20
and work with layer 8 (users/engineers),=20
but there is absolutely nothing you can do with layer 9 (Management).
As for why anyone would use ATM (B-ISDN):
(11) Every old idea will be proposed again with a different name and
a different presentation, regardless of whether it works.
--JP
---------------------------------------------------------------
"No matter how hard you push and no matter what the priority,
you can't increase the speed of light."=20
Fundamental Truth #2 -- RFC 1925
---------------------------------------------------------------
------=_NextPart_000_000C_01BF20D8.DD161560
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>----- Original Message ----- </FONT>
<DIV><FONT face=3DCourier size=3D2>From: Vadim Antonov <<A=20
href=3D"mailto:avg@kotovnik.com">avg@kotovnik.com</A>></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>To: <<A=20
href=3D"mailto:abender@tns-inc.com">abender@tns-inc.com</A>>; <<A=20
href=3D"mailto:scharf@vix.com">scharf@vix.com</A>></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Cc: <<A=20
href=3D"mailto:nanog@merit.edu">nanog@merit.edu</A>></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Sent: Tuesday, October 26, 1999 5:05=20
PM</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>Subject: Re: Traffic engineering=20
tools</FONT></DIV></DIV>
<DIV><FONT face=3DCourier size=3D2><BR> </DIV></FONT>
<DIV><FONT face=3DCourier size=3D2>> TE [snip] simply reallocates =
existing=20
resources differently.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>></FONT></DIV>
<DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>In reading your mail, I'm reminded of =
one of my=20
favorite RFC's...</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>"The Twelve Networking =
Truths"</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2> (10) One size never fits =
all.</FONT></DIV>
<DIV><BR><FONT face=3DCourier size=3D2>On the whole as a global =
solution, I would=20
agree with you that different is not necessarilly better, and =
sub-optimal=20
routing is not the best of solutions. There is an ISP we deal with who =
bounces=20
their traffic around the network until it finds an available exit. All =
the exit=20
points are nearly equally balanced, but the network as a whole is=20
slow.</FONT></DIV></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>In some specific cases however =
(mostly peering),=20
the peer's dynamic routing chooses what it believes to be the optimal =
exit path=20
by choosing 'closest gateway'/'nearest exit' routing. In =
these<FONT=20
face=3DCourier size=3D2> cases, sub-optimal utilization of your own=20
external connections by the peer creates severe congestion/loss.=20
</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>As an example I would present a peer =
with=20
multiple connections to your network in topologically distributed =
locations (ie.=20
opposite sides of your network). If the peer is utilizing one link in =
one=20
direction at 80% and the other two at 10%, you need to make some =
adjustments in=20
local pref, or redirect your outbound traffic destined for that peer (or =
his=20
downstreams) to the peer's underutilized path(s). Otherwise you're going =
to have=20
packets all over the floor at the link with 80% utilization. =
(!)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>TE is necessary more often than most =
would care=20
to admit, and occurs mostly at network borders, because none of the=20
carriers/providers like having to pay for additional external =
connectivity any=20
sooner than they absolutely _have_ to.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>If you are a large provider with a =
large number=20
of multiply-connected peers, traffic engineering (though rare) is a fact =
of=20
life. Of course from an implementation standpoint Truth number 6=20
says:</FONT></DIV>
<DIV><BR><FONT face=3DCourier size=3D2> (6) It is =
easier to move a=20
problem around (for example, by=20
moving<BR> the problem to a =
different=20
part of the overall =
network<BR> =20
architecture) than it is to solve it.<BR></FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>..aww, heck, from any =
standpoint.</FONT></DIV>
<DIV><BR><FONT face=3DCourier size=3D2>> Note that customers do not =
generally=20
care about bandwidth. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>You didn't actually think I'd let =
this one slide,=20
did you?</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2>Next time _you_ can talk to the guy =
who's whining=20
that his 1.544Mb T1 (ESF, AMI, B8ZS & TCP/IP) is only =
getting ~1.4Mb=20
throughput (and of course, he's testing it with a web browser). =
After all,=20
he's paying for bandwidth, and he's the customer, and the customer is =
always=20
right. ;-)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>> [the solution is] adequate =
provisioning=20
and capacity planning </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>Which of course is the BEST way to =
handle most=20
network problems, IF you have the money. ;-) Which brings me to the =
corollary to=20
fundamental truth number 7:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2> =
Good, Fast,=20
Cheap: Pick any two (you can't have all three).<BR></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>> I strongly suspect that is =
because there are=20
no real<BR>> measurable benefits - and that TE is being used mostly =
to cover=20
up<BR>> planning problems and as a short-term fix to idiocies at =
a<BR>>=20
transmission level.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>Of course there are benefits! They =
just don't=20
have anything to do with the network. Why spend $1,000's on new =
pipes/routers=20
when you can solve your problems for (almost) free by buying whatever =
will allow=20
you to tweak your routing and 'optimize your utilization of existing=20
resources'.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>(I cut and pasted that from a certain =
vendor's=20
marketing literature)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>Vendor Marketing plays on your =
Management's=20
fears. There's nothing that scares management more than justifying =
money=20
spent, especially money spent for 'unneeded' resources. The fact that =
that shiny=20
new gigabit pipe WILL eventually be fully utilized is immaterial. It's =
not being=20
used NOW.</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2></FONT> </DIV>
<DIV><FONT face=3DCourier size=3D2>Small money is a small risk, and =
traffic=20
engineering alleviates the problem at the problem point sufficiently to =
make it=20
appear that it has gone away. It does this for minimal cost expenditure, =
which=20
is an 'optimal' solution where management is concerned.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>Which brings me to my own personal=20
addage:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2> You can troubleshoot =
layers 1-7,=20
</FONT></DIV>
<DIV><FONT face=3DCourier size=3D2> and work with layer 8=20
(users/engineers), </FONT></DIV>
<DIV><FONT face=3DCourier size=3D2> but there is absolutely =
nothing you=20
can do </FONT><FONT face=3DCourier size=3D2>with layer 9=20
(Management).</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>As for why anyone would use ATM=20
(B-ISDN):</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2> (11) Every old idea will =
be proposed=20
again with a different name =
and<BR> a=20
different presentation, regardless of whether it works.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT face=3DCourier size=3D2>--JP</FONT></DIV>
<DIV><BR><FONT face=3DCourier=20
size=3D2>---------------------------------------------------------------<=
/FONT></DIV>
<DIV><FONT face=3DCourier size=3D2>"No matter how hard you push and no =
matter what=20
the priority,<BR>you can't increase the speed of light." <BR>Fundamental =
Truth=20
#2 -- RFC 1925</FONT></DIV>
<DIV><FONT face=3DCourier=20
size=3D2>---------------------------------------------------------------<=
/FONT></DIV></BODY></HTML>
------=_NextPart_000_000C_01BF20D8.DD161560--
