Re: Traffic engineering tools
Traffic Engineering is like Quality of Service - it doesn't create any more bandwidth by magic, and simply reallocates existing resources differently. That established, we have two courses of action - the first, is to bulild overcomplicated networks and then try to fix resulting suboptimal routing with TE. The second option is to simplify topologies by replacing clusters of routers with scalable and inherently fault-tolerant devices (guess which ones i have in mind :) In a long-distance backbone where routers connected directly to fibers, and where there's no overlay of level-2 topology, the cost of deliberate misrouting (sending packets down paths different from shortest) is simply too high to justify any benefits it brings. The intermediate virtual circuit layers simply obscure the fundamentals by making paths inherently non-optimal (if you do not plan to use SONET or ATM VCs to create topologies which do not match physical paths, why whould you want to install it?) Note that customers do not generally care about bandwidth. The name of the game is latency at a given load. Misrouting packets simply increases latency. So. Benefits of TE as compared with simpler and more robust techniques (such as adequate provisioning and capacity planning :) weren't demonstrated in practice. I have yet to see any real backbone operator saying something like "we've got 30% less latency because we do TE". 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. That is a very thin justification for replacing technology which is known to work with a very new can of worms. My personal theory on QoS and TE hoopla is that this is a FUD tactics used by Cisco to raise entry barriers for other vendors - and to con customers into buying more of their irrelevant ATM stuff. --vadim PS There were tons of research and articles on best methods of CPU and memory scheduling. In restrospective, building faster processors turned out to be the soultion. Even if they're 99% idle. Meanwhile, the vendors which were keen on doing detailed accounting stuff nearly all are history by now.
From: Jerry Scharf <scharf@vix.com> ... I do believe that some of the TE folks are punting the general case solution by only attempting to do TE and protection on a small potion of their traffic. If you have a glut of web traffic that acts as a sponge, you can get away with nonoptimal management of the subset without causing meltdowns.
----- Original Message ----- 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" (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. 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.
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
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, and work with layer 8 (users/engineers), 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." Fundamental Truth #2 -- RFC 1925 ---------------------------------------------------------------
participants (2)
-
John Patteson -
Vadim Antonov