Remember too that if you have multiple types of flows on your link (FTP, TELNET, HTTP) the key isn't so much to utilize your DS3 99% as it is to ensure that the end user's expectations aren't upset. So, you might use WRED to drop bulky FTP packets instead of Voice, Video, Telnet, some HTTP, etc...in those cases where you reach the threshold that you specify. Does an FTP user really notice if their download starts at 160kbs and gyrates around between 30-150kbs..especially if they are very large downloads? But a web page taking 12 seconds to load...not good. -----Original Message----- From: smd@clock.org [mailto:smd@clock.org] Sent: Wednesday, February 20, 2002 1:02 PM To: nanog@merit.edu Subject: red [was Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?] randy bush writes: | you can turn on [x]red. it will make a better choice of which packets | to drop. but packets will still be dropped [0]. fsvo "better". red drops packets randomly, a little earlier than packets will be tail-dropped by being unable to find buffer space in a queue. in most cases, tail-drop is worst for TCP connections in slow-start, and leads to such fun things as web-page-slowdown-syndrome, or ssh-stall-syndrome, with the attendant hitting of the "reload" button or frustrated banging on the keyboard trying to get one's keys to echo back, or trying to unstick the page of text being sent to /dev/tty on the remote end. "r" for random: this spreads out loss randomly, and in most cases, this means that several different TCPs each observe a single lost segment, which is quickly detected and causes an attendant slow-down, but not a stall. "e" for early: we have to keep the queue from filling, because that leads to tail-drop, so we have to drop packets when we could really send them. there is no way around this -- in virtually any implementation, the mechanism to turn on red can be translated into more fifo-queue space. the trade-off (early random dropping) is usually worth it. there are some corner cases where there is insufficient ability to spread drops across enough flows, where resulting behaviour can be alot like tail-drop (a huge difference between fast input speed and slow output speed, with only a few bulk-transfer flows), but these cases are rare, particularly where average_segment_size / bottleneck_kbps <= 0.4, with the 0.4 being a historical minimum target for queueing in the presence of flows which experience long RTTs (like ones across oceans). in general, you don't have to worry about that, though. | you can increase buffers blah blah blah. but twenty tomatoes will still | not fit in a fifteen tomato can. yup, the trick is to deploy a red control law that drops just before tail-dropping would start, so we don't lose packets unnecessarily, yet early enough before tail-dropping would start that the senders have time to back off in response to the detected lost segment, which is driven by the RTT. drop too early, and you get an underused line. drop too late and you get tail-drop, which also gives you an underused line. drop just right, and you can keep your line very very very close to 100% for sustained periods of time (hours!), assuming a large enough set of TCP flows that random dropping spreads the early dropping across different flows. | [0] - corollary: qos mechanisims decide which packets to drop. but isps | are paid not to drop any packets. it is impossible to get 0 drop and enjoy statistical multiplexing gain. statmux gain keeps the network cheap enough to use. red minimizes the liklihood that anyone will complain about performance during those inevitable periods when one's statistical bet goes wrong. Sean.