From craig@NNSC.NSF.NET  Wed Jun 21 05:11:45 1989
Posted-Date: Wed, 21 Jun 89 08:09:20 -0400
Received-Date: Wed, 21 Jun 89 05:11:45 -0700
Message-Id: <8906211211.AA21269@venera.isi.edu>
Received: from WS6.NNSC.NSF.NET by venera.isi.edu (5.61/5.51)
	id <AA21269>; Wed, 21 Jun 89 05:11:45 -0700
Received: by NNSC.NSF.NET id aa00503; 21 Jun 89 8:10 EDT
To: Z.Wang@cs.ucl.ac.uk
Cc: end2end-interest@venera.isi.edu
Subject: re: more on fair queueing
Date: Wed, 21 Jun 89 08:09:20 -0400
From: Craig Partridge <craig@NNSC.NSF.NET>
Status: R


> Nagle's version of fair queueing is fair to individual
> sources not to users. The sources with more users will suffer.
> But fair queueing only becomes very effective when the network
> is over-loaded. The sources with heavy traffic will be then
> in big trouble (deserved?). 

Zheng:

    My view is that treating all sources as equal is clearly wrong.
The easiest example is a Cray and PC on the same network, sharing a
gateway.  Saying that, during congestion, all the users on the Cray
should get just as much bandwidth as a single user on the PC is,
in my view, nonsense.

    At a higher level, I suspect we have architected the Internet 
in such as way that some hosts are much much more important and generate
proportionally more traffic than others, and that a failure to recognize
this is likely to lead to the collapse of the Internet.  Some cases in
point:

    + E-mail.  We have some big e-mail gateways (uunet.uu.net, relay.cs.net,
	cunyvm.cuny.edu, ucbarpa.berkeley.edu, etc.) which handle a
	large fraction of the Internet mail.  If those systems become
	clogged, eventually, their backlog ripples back to other hosts.
	(For example, when relay.cs.net gets severely overloaded, the
	operating system starts to thrash, and the system is slower
	to reply to SMTP commands  -- as a result, some remote systems
	time out relay, and are forced to keep mail on *their* queues
	until relay's load goes down.  We discovered this pent-up traffic
	phenomena during the Arpanet congestion collapses of a few years
	ago).

    + The domain system.  The domain system reportedly is  responsible for
	over 30% of the traffic on the NSFNET backbone.  In my experience,
	much of that traffic probably goes to the root servers.  If we
	limit the bandwidth available to get to root servers, then at
	best, name lookups will take longer, at worst we will have
	congestion collapse as most of our broken domain querying software
	mindlessly retransmits queries into the congested network.

Scott's proposal to doing queueing on source-destination pair makes this
problem less severe, but I suspect may cause milder failuers if there
are certain hot src-dest pairs (say relay.cs.net to cunyvm.cuny.edu)
that affect Internet performance.  (Again, this is conceivable -- when
either the BITNET or CSNET gateway is out of service very long, the
other one begins to overload...)

It is to answer this question of hot src-dest pairs that leds me to
want to do some traffic watching.

Craig