🚀 go-pugleaf

In article <1a817gINNmn2@nigel.msen.com>, emv@msen.com (Edward Vielmetti) writes:
> Jim Rees (rees@pisa.citi.umich.edu) wrote:
> : 
> : I don't understand why this queueing was done on the basis of tcp port
> : number rather than packet size.  Wouldn't it be far more general to put all
> : packets below a certain size on the fast queue?  I know this would result in
> : some packet re-ordering within connections, but that should be ok.
> 
> my guess is that this would do perverse things to round-trip estimators,
> and that you'd have tcp implementations getting confused about just how
> fast and how congested the link was.  e.g. the acks would come back "too
> fast" and overly encourage the production of new big packets to clog the link.
> 
> you'd want to try it out to see, of course, but i suspect that in general
> you'll have better results if you skew performance on a per-connection
> basis rather than a per-packet basis.


Using packet size works fine for me with SLIP.  I have never noticed
any RTT related oddities.

It seems much cleaner to look at packet sizes than having a list of
"interactive" port numbers wired into a kernel driver.  Which port
numbers would you use?  How do you handle local interactive protocols?
What about interactive ports dynamically allocated by the RPC
portmapper?  Are rsh port numbers "interactive"?  What about rcp
traffic?  What about X--much of it is clearly interactive, but some of
it will saturate a T3 link for as long as you want to pay for it.

Of course, you have to check both the source and the destination port
number.

Feel free to buy an SGI machine and check it out for yourself.  Don't
forget to tell the salescritter who sent you.  I won't get any
commission, but maybe they'll stop saying those things about me.

Slow start does terrible things on very slow links if your hosts use
windows larger than the queues on the links.  Eventually it causes a
lost packet, and then a retransmission of a window's worth.  That has
caused me far more irritation than any bogus RTT values.

I do wish common non-PPP routers would do some, any kind of TOS
queuing.  The default window size on SGI machines is 60K (helps FDDI
benchmarks).  Trying to use the SGI corporate WAN for interactive
traffic while someone is rcp'ing a 600 MByte CDROM over the same 56K
links is Not Fun.  Character echos suffer 6-12 second delays.
(again, should "rsh" be counted "interactive" traffic?)


No matter what TOS queuing you use, if you use Telebit modems, it pays
to reduce the 3.5KBytes of in-the-modem buffering with PEP.  They gave
me a secret, magic S register to do that.  I decided it wasn't worth
the customer hassles with new modems to ship configuraton files to use
it and so forgot it.


Vernon Schryver,  vjs@sgi.com