From craig@NNSC.NSF.NET  Thu Mar 30 09:58:12 1989
Posted-Date: Thu, 30 Mar 89 12:56:21 -0500
Received-Date: Thu, 30 Mar 89 09:58:12 PST
Message-Id: <8903301758.AA14975@venera.isi.edu>
Received: from WS6.NNSC.NSF.NET by venera.isi.edu (5.54/5.51)
	id AA14975; Thu, 30 Mar 89 09:58:12 PST
To: van@lbl-csam.ARPA
Cc: end2end-interest
Subject: congestion policies in bridges
Date: Thu, 30 Mar 89 12:56:21 -0500
From: Craig Partridge <craig@NNSC.NSF.NET>
Status: R


Van:

    I was typing in the E2E notes for Bob today and ran across a comment
you'd made about congestion control that tickled a memory.

    You noted that Dave Mills' Fuzzball algorithms in NSFNET worked pretty
well because the Fuzzies could buffer the entire delay * bandwidth product
of the network and thus when they were forced to drop packets, the queues
they were examining represented a complete RTT cycle through the network
(and thus any decisions you made about who to drop could reflect a complete
picture of the network load).

    This was a prelude to arguing that we couldn't expect to buffer
that much in gigabits networks and thus needed some other method
to figure out how to apportion the load but I caused me to think of
a conversation I had with Mario Gerla at the last SIGCOMM.  He was
interested in putting better congestion control algorithms into
LAN bridges (apparently the current practice in bridges is to throw
out the entire queue if it overflows).  And I wonder if the argument
about the Mills algorithm doesn't apply to bridges even on gigabit
LANs.  We can certainly buffer the delay * bandwidth product within
the bridge LAN in each bridge.  Then we could apply our congestion
policy over a complete RTT cycle...  Am I missing something?

Craig