RED experiment data

On February 27, 2001, I started monitoring packet drops on our University's Internet border router's WAN link. The Internet link speed was 18 Mb/s on a fractional DS-3 to the UUnet pop in Chicago. The LAN interface to the University was a full-duplex 100 Mb/s ethernet link. The router is a Cisco 7206 running 12.0(11.6)S IOS. At that time, the WAN link was NOT setup to do any time of active queue management nor was it configured to do any fair scheduling.

On the evening of March 22, I enabled RED on the Internet border router's WAN interface with the following parameters:

• random detect
• random detect precedence 0 10 40 10
• random detect precedence 1 10 40 10
• random detect precedence 2 10 40 10
• random detect precedence 3 10 40 10
• random detect precedence 4 10 40 10
• random detect precedence 5 10 40 10
• random detect precedence 6 10 40 10
• random detect precedence 7 10 40 10
• random detect precedence rsvp 10 40 10

The above configuration sets all IP packets to be treated equally, reglardless of their ToS field settings. The parameters are as follows:

• min_sh (minimum threshold)


When the average queue size is less than min_sh, no packets will be marked. 10 seemed like a fairly conversative value.


• max_th (maximum threshold)


When the average queue size is greater than this value, all packets are marked. I also set this to a fairly conversative value of 40. Note: the default queue size on our Internet border router was also 40 when RED was not enabled.


• max_p (upper bound on marking probability)


As recommended by Sally Floyd, this is set to 0.1. See RED Parameters discussion.

During the time packet drops were being monitored, but before RED was enabled, traffic from the University to the Internet was consistently heavy during peak usage hours (10 a.m. to midnight). Much of the outbound traffic was identified as file sharing applications such as Napster. RED was enabled just as the University's Winter quarter was ending. Therefore, it would be a few weeks before we saw any impact with RED. Surprising, the average traffic utilization from the University to the Internet in the following Spring quarter was lower. This lower average outbound utilization appears to be attributed to the effectiveness of the mandated filtering applied by Napster and possibly other similar services.

After an email from Sally Floyd on May 1, 2001 asking how RED was doing for us, I started to see if I could provide her with some worthwhile data. It just so happened that on May 2, 2001 we had begun seeing heavy outbound traffic. Interestingly, the increase was due to a Windows machine on campus having been compromised and was being used to distribute copyrighted material via ftp. Before it was disabled however, I seized this opportunity to perform some queue management comparisons with both RED enabled and disabled. I was still watching packet drops so along with the traffic utilization and classification of data, the information below shows the results with and without RED. With each of the graphs, I'll point out where RED was enabled, disabled and the time periods of the graphs. Outbound traffic is traffic from the University to the Internet. This is where RED is applied on the WAN interface.

The following graphs show historic packet drop and traffic utilization data before RED was enabled. These graphs were saved an hour after RED was enabled (most recent time is to the right of the graph).

• March 22, 2001
• RED enabled at 2030 hours (far right)
• Packet drops versus traffic utilization

• Week of March 15 through 22, 2001

• End of February through March 22, 2001

The following graphs show historic packet drop and traffic utilization data after RED was enabled. In addition, during the most recent period of high outbound traffic, RED was temporarily disabled and re-enabled twice to help show the effect it had compared to default tail drop queueing.

• May 2, 2001
• RED disabled at 1200 hours (far right)
• RED was re-enabled at 1215 hours (far right)
• RED was disabled at 1315 hours (far right)
• RED was re-enabled at 1345 hours (far right)
• Compromised FTP host shut down at 1400 hours (far right)

• Week of April 26 through May 2, 2001

• April and Beginning of May, 2001

• May 2000 to May 2001

Last updated: May 2, 2001