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 ; 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 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