Path: utzoo!mnetor!uunet!husc6!bbn!rochester!pt.cs.cmu.edu!IUS3.IUS.CS.CMU.EDU!ralphw
From: ralphw@IUS3.IUS.CS.CMU.EDU (Ralph Hyre)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  SLIP working group?
Message-ID: <1455@pt.cs.cmu.edu>
Date: 18 Apr 88 23:14:38 GMT
References: <8804150036.aa13833@Huey.UDEL.EDU>
Sender: netnews@pt.cs.cmu.edu
Organization: Carnegie-Mellon University, CS/RI
Lines: 28

In article <8804150036.aa13833@Huey.UDEL.EDU> Mills@UDEL.EDU writes:
>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
... 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
>... I can't say you should all go rush out and implement it. 
>... 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.
One might imagine something based on 'deadline scheduling', where a 'deadline
to transmit', at which point some other layer will presumably retransmit.
Theoretically (don't ask me - I can't prove it - I just heard it from an
operating systems talk at another institution four years ago.) you can meet
all the deadlines by picking the packet with the closest deadline first.
[This assumes that all the deadlines can be met -- if they can't then you
have a network enginerring problem which is beyond the scope of this message]

Still not happy with interactive response?  Then fragment those big packets
and get the SLIP at the other end to unfragment them!
Vendors everywhere will thank you for fully testing conformance of their
TCP/IP implementations.
-- 
					- Ralph W. Hyre, Jr.

Internet: ralphw@ius2.cs.cmu.edu    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA