North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: red [was Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?]

  • From: Brennan_Murphy
  • Date: Thu Feb 21 17:10:10 2002

Title: RE: red [was Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?]

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, 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: [email protected] [mailto:[email protected]]
Sent: Wednesday, February 20, 2002 1:02 PM
To: [email protected]
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.