From Shenker.pa@Xerox.COM  Wed Jun 21 16:48:17 1989
Posted-Date: 21 Jun 89 16:32:18 PDT (Wednesday)
Received-Date: Wed, 21 Jun 89 16:48:17 -0700
Received: from Xerox.COM by venera.isi.edu (5.61/5.51)
	id <AA14631>; Wed, 21 Jun 89 16:48:17 -0700
Received: from Burger.ms by ArpaGateway.ms ; 21 JUN 89 16:32:36 PDT
Date: 21 Jun 89 16:32:18 PDT (Wednesday)
From: Shenker.pa@Xerox.COM
Subject: Re: more on fair queueing
In-Reply-To: <8906212150.AA00735@braden.isi.edu>
To: end2end-interest@venera.isi.edu
Cc: craig@nnsc.nsf.net, braden@venera.isi.edu, lixia@lcs.mit.edu,
        shenker.pa@Xerox.COM
Message-Id: <890621-163236-18260@Xerox>
Status: R

Three comments on the need to be unfair:

0)  I second Lixia's comments. 

1)  Unless a line is always fully utilized (and assuming we have
intelligent flow control algorithms that can adjust to congestion), using
FQing at the gateway does NOT change the overall long-term bandwidth
allocations (the instantaneous bandwidth allocations are changed, but the
hogs get to sop up the leftover bandwidth).  FQing merely changes the delay
allocations.  Thus, FQing does not prevent a hot pair from using 25% of the
bandwidth, but rather it merely imposes extra delay on that hot pair's
traffic.  Thus, the "unfairness" issue becomes especially important when
traffic is time-critical (Does mail fall into that category?  I know about
mail backing up (as Craig described), but what kind of time-scale are we
talking about (is it faster than the regeneration times of the GW)?  The
domain traffic is probably more time-critical, but are there hot
source-destination pairs there?).  Craig, in answer to your question about
what measurements to make; it seems crucial that we get detailed enough
data so that we can make quantitative statements about how much mail (or
domain) traffic would be delayed by implementing FQ.

2)  One way of phrasing the question is: are we going to design networks
where legitimately hot pairs have time-critical traffic that would exceed
their "Fair Share"?  In addition to the question "do we need to be
unfair?", one can also ask "how much bandwidth would we have to buy in
order to make being fair OK?".  The current discussion is over whether we
have enough bandwidth right now, which is a very important question (keep
that data coming Craig!).  However, I just want to make the point that the
design of the network and the fairness issue are intertwined.  

3)  Assume that the network would collapse if FQ were implemented.  We then
have to ask the question, how is it possible that the network functions
now?  There are several scenarios that one can consider (audience
participation is expected here; send in your own)

A)  The net functions now, but will fall apart with FQ because some
critical network links are completely overloaded (line is busy 24 hours a
day).  Putting FQ in the gateway will change the bandwidth allocation, thus
depriving the hot pair of needed bandwidth.
 
B)  The net functions now, but will fall apart with FQ because
(1)  hot pairs currently get more than their "instantaneous" fair share.
This could be due to:
		(a) they open many streams
		(b) they have smaller RTT's than most of the other sources
		(c) they cheat on the flow control algorithm
		(d) the "segregation" phenomena keeps other sources out
		
(2)  hot pairs are relying crucially on the lower latency they are getting,
and the network collapse is due to their traffic being slowed down.

C)  The net functions now, but will fall apart with FQ because once
low-throughput pairs get decent service at gateways, traffic patterns will
change so that the hot pairs will eventually get squeezed out by either
scenario A or B above.   
  
  
Any others scenarios?  
  
  Scott