Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

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

  • From: Sean M. Doran
  • Date: Wed Feb 20 13:06:28 2002

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.




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.