News Stay informed about the latest enterprise technology news and product updates.

Dr. Network: Traffic shaping is art, not science

Dr. Network says traffic shaping is an art, not a science.

By Greg Ferro, Contributing Editor

Read about Greg

Listen up, people. And listen up good. I am very tired of repeating the same old line over and over.

Traffic shaping -- it's an art.

In the last couple of months, I have been working on projects that require a lot of traffic shaping. Let's forget simple prioritization or queue management. I am talking about trying to get a golf ball down a garden hose here.

Now, implementing really good traffic control is more art than science. To an outsider, what we are doing is tweaking knobs, changing a bit of this and standing back to see what is going on. And that impression is pretty accurate. This is art.

Let me try to explain. To be really good at traffic shaping, you have to understand a whole range of technologies. For example, let me show you a short introductory list:

  • Buffers and buffer management
  • FIFO, Fair Queue, Weighted Fair Queueing
  • Random Detection, Random Early Detection
  • Diffserv and Intserv
  • Class Based Weighted Fair Queueing
  • Traffic identification and classification
  • Vendor software architecture

After you understand all of those technologies, you need to understand all the applications that are crossing your network. So your network guy needs to understand the traffic profile of things like Citrix, Notes, MS SQL, MS Exchange, NetBIOS, Oracle, SMTP/POP, etc., etc., etc.

Just for added spice, you also need to know about frame relay burst capabilities, the various capabilities of WAN links and how they respond under load conditions. You will also want to have some knowledge in implementing all these features on your favorite router. And be warned, it doesn't always work as advertised.

Traffic shaping has a lot of science in there -- and I mean a lot. But when you put it all together and apply it to a network, it's like trying to tie someone up with a rope of sand. So your network guy (that's me) has to listen to you explain what you want.

Fair enough, you say. But you often don't know what you want. Not really. You often think you do, but you don't. Let me give you a scenario that's close to real life:

You have a 256K bit/sec frame relay connection. It runs at an average utilization of about 60% during the working day. Your Citrix users are complaining that the performance is lousy.

Okay, point one -- describe lousy performance under Citrix. Are you saying that the software is waiting, or that the screen refreshes slowly? (Ohhh, you've never thought about it, have you?) If the screen is slow, that's a traffic problem.

So I go to your network and make some changes to improve Citrix performance. I implement some fancy traffic shaping to adapt the traffic flows into the frame relay network. Then I implement simple buffer management to ensure that Citrix gets top priority for transmission.

A couple of days later, I get a call. You got a call from the SAP people, who say that the SAP access is a lot slower. So we get together and decide that we need to improve telnet performance. But now I have to make sure that there is enough bandwidth for Citrix as well. We discuss how we can reprioritize other traffic to ensure that there is enough bandwidth given to Citrix. We decide to bandwidth-limit our MS Exchange mail traffic. I reluctantly implement a fancy queuing technology. I know that it is going to go downhill from here.

Sometime later, I get a call that Exchange performance is not good, and there are still some performance issues with SAP users. Hmm. Some more time is spent attempting to analyze where the bottleneck is. After about three days we realize that some fool is sending 100M byte e-mails across the network. Hmm. We decide to bandwidth-limit MS Exchange to a maximum of 64K bit/sec, or about a quarter of the frame relay link. That will ensure that e-mail traffic doesn't swamp the link. The router config is starting to look ugly.

Sometime later still, I get a call. The Exchange server has got a couple of thousand messages in the output queue to the Exchange server in the other location. Apparently, 64K bit/sec isn't enough. We increase the Exchange server to 96K bit/sec with a burst capability. I decide to add Random Early Detection to improve the sustained throughput. Further, we decide that NetBIOS traffic between the sites should be rate-limited to no more than 96K bit/sec with a small burst to avoid swamping the main traffic flows.

And even later, the Intranet isn't performing very well. So we add another class to the queue to identify traffic to the Web server. But hang on, we have several Intranet servers. Hmm. So we decide to use URL detection by renaming all internal Web servers with "wwwin" as the hostname. Thus any Web page that has "wwwin.marketing.acme.com" as part of its address will be prioritized over general Internet Web access.

Of course, making this change requires a router upgrade and outage on the network.

Some weeks later:

Network Manager: Well, Dr. Network, people are complaining that the traffic shaping isn't working very well.
Dr. Network: Do we have any specific information on those complaints?
Network Manager: No, just a lot of complaints that it isn't going very fast.
Dr. Network: Are you sure the problems are on the network and it's not the fileserver causing the bottleneck?
Network Manager: I don't have any information on that.
Dr. Network: Let's review the changes that we made so that you can clearly understand what we have done so far.

Ten minutes of me watching that "look" on Network Manager's face…

Dr. Network: It might be time to upgrade the bandwidth. As you can see, there isn't much more that we can achieve using traffic shaping.
Network Manager: We can't afford that. It would cost us $20,000 per month to upgrade the bandwidth across our sites.
Dr. Network: Well, we can keep trying to manage the bandwidth, but really we are trying to fit a golf ball down a garden hose.
Network Manager: But all the money that we spent on traffic shaping…
Dr Network: You saved $20,000 a month for the last six months by not upgrading the bandwidth, so you actually have saved about $100,000. You've got to admit, that's pretty good.
Network Manager: But we can't really tell how well it's going.
Dr Network: Remember what I told you in the beginning? Traffic shaping is an art, not an exact science.

You see, I really need you to listen up. Traffic shaping and quality of service are a good idea, just be prepared to pay for someone who knows their stuff do it for you. And don't offend them by criticizing their work. It's ART.

Meet SearchNetworking.com's Dr. Network, Greg Ferro.

Do you agree with Greg? Think he's full of beans? Let him know in the Dr. Network Forum.

Dig Deeper on Network management and monitoring

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close