Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!pasteur!ucbvax!UDEL.EDU!Mills
From: Mills@UDEL.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  SLIP working group?
Message-ID: <8804150036.aa13833@Huey.UDEL.EDU>
Date: 15 Apr 88 04:36:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26

Steve,

Yes, if what you mean by "fair queueing" (a term I find mesleading at best)
is multiple priority queues in the conventional sense, the fuzzball gateways
used on the NSFNET Backbone and at several other spots scattered over the
US and Europe do that for all network links, including SLIP. The scheme is
based on the Precedence field of the IP header, plus a few naughty tricks
based on port number (when the precedence field is zero). Having used the
scheme a lot on slow (9600 bps) serial links with SLIP and other link
protocols, I can't say you should all go rush out and implement it. As
implemented in the fuzzballs, priority scheduling ruthlessly shoves interactive
traffic to the head of the queue, even if bulk-transfer (FTP, mail) traffic
ends up waiting indefinitely at the end, then timing out. Then, little
things like miscellaneous UDP and ICMP (ping) services sometimes stop
working. Obviously, fancier service disciplines can be designed which would
be more "fair," but the fuzzies have not yet learned those tricks.

My point is not to discourage innovation in this area or even to conclude
the fuzzball scheme does not work right; on the contrary, most of the time
it works like a bandit. However, I do want to point out that the fairness
issue is much more complex than you might suspect and deserves careful study
in its own right. One of the most fertile experimental breeding swamps may
well be hoked-up SLIP drivers for exactly the service you describe. After
all, there are hundreds of times more Unix systems out there than fuzzballs.

Dave