Subject: protocol independent congestion control?

From: [email-masked] (Tim Dorcey)
Date: Tue, 27 Aug 1996 14:35:25 -0700

This is a little off the track of the int-serv mission; perhaps someone can
suggest where would be more appropriate.

Most would agree that TCP congestion avoidance has played a major role in
the successful growth of the Internet.  Instead of producing catastrophic
failure, attempts to over-utilize network capacity result in gradual
performance degradation for everyone.  The network remains useable (and
continues to generate income/value), allowing operators to plan and deploy
additional capacity in a systematic fashion.

It remains an open question how the Internet will respond to increasing
volumes of non-TCP traffic dictated by the demands of real time
applications.  Also, as Internet use becomes increasingly competetive, it
may be only a matter of time before "high performance" implementations of
"TCP," parameterized to gain a more aggressive share of bandwidth, are in
use.  Possibly, firewall operators could learn the signature of rogue TCPs
and filter them out, but a more general solution would have many benefits.

Is anyone considering this sort of problem?  I was thinking a very simple
scheme might work as follows:  if a network forwarding agent has dropped
more than P packets from source S in a given time interval T, then it
begins dropping all packets originating from S for some time interval B.
Rather than banning particular protocols or ports, particular sources would
be (temporarily) banned based upon observed behavior.  Any protocol
(implementation or parameterization) that did not respond sufficiently to
packet loss would ultimately be useless (in situations where loss could
occur).  Protocols without feedback mechanisms to detect packet loss would
need to use RSVP or some other reservation scheme to insure that packets
would not be lost in the first place.  In that regard, new protocols could
be more rapidly deployed, if network operators knew there was a built in
safety mechanism operating at a lower level, rather than relying on a list
of "trusted protocols."

Does this make sense?  Does observation based filtering already operate
within existing firewalls, or do they rely entirely on static configuration
by protocol/port/address?  Would it be feasible to add this kind of logic
to routers?

Tim

Tim Dorcey
BoxTop Interactive

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 04 Oct 1996 08:59:20 +0100

what you asking about is generalized adaptive protocols and it is
close to the heart of a lot of us, who are not sure about how
deployable resource reservation  is in a multi-provider environment
(or at least at the level of per-source/destination session - rsvp per
virtual private intranet over the wide internet is reasonable...)

 >by protocol/port/address?  Would it be feasible to add this kind of logic
 
the design of RED is very much along these lines, although I am not
sure how much has been written up on syn bins and other techniques for
dealing differently with session start and existing sessions.......

see
http://ftp.ee.lbl.gov/floyd/red.html
for papers on this

LBL and other people are working on adaption in other contexts (for
example congestion avoidance for multicxast applications is a decidedly
non trivial problem) - i can cite papers on various schemes (see
sigcomm - pages from http://www.acm.org/sigcomm/
for links to papers on multicast congestion avoidance for layered
video, for IVS and other things .... see also the links from
http://www.cs.columbia.edu/~hgs/netbib/
for multicast congestion....and for adaptive protocols.....

there is also work by dave clark on profiling applications so we can
optimise the behaviour of routers w.r.t social and anti-social
behaviour of end systems.....

i think i hold out a lot of hope for this approach to a scalable
internet (more than for per-user RSVP, for example)

having said that, the int-serv work is very usaeful in specifying just
exactly wehat service a given classified flow might get - we could
envisage an entirely controlled load internet one day:-)

regards

 jon

---

From: Arthur Lin <[email-masked]>
Date: Fri, 04 Oct 1996 06:46:30 -0700

> dealing differently with session start and existing sessions.......

RED is available in 11.2 of cisco routers.

-arthur

---

From: Andrew Heybey <[email-masked]>
Date: Fri, 04 Oct 1996 10:17:27 -0400

J.Crowcroft> the design of RED is very much along these lines,
  J.Crowcroft> although I am not sure how much has been written up on
  J.Crowcroft> syn bins and other techniques for dealing differently
  J.Crowcroft> with session start and existing sessions.......

Vaguely along these lines a simple version of RED has been implemented
in *BSD to foil SYN flooding attacks.  RED is performed on the
embryonic connection queue, so that when the queue becomes congested
partially-open connections will be dropped from the queue randomly.
Since the bogus connections dominate the queue, they are much more
likely to be dropped than a legitimate connection attempt.

andrew