Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!hplabs!hpda!hpcupt1!hpindwa!raj
From: raj@hpindwa.cup.hp.com (Rick Jones)
Newsgroups: comp.protocols.tcp-ip
Subject: Why Fewer Buffers (was Changing TCP port)
Message-ID: <36540021@hpindwa.cup.hp.com>
Date: 11 Feb 91 02:33:35 GMT
Organization: Hewlett-Packard, Cupertino CA
Lines: 40


>In a different string, it was asked why cisco might suggest using
>fewer buffers on slower links...

There is probably a more fundamental reason for cisco's statement
about using fewer buffers on slow-links:

Keeping response time (RTT/SRT/etc) small.

If you give a TCP the space, it will use it in an effort to maximize
thruput - perhaps not 'consciously' ;-) but by always sending as many
packets at a time as it can/is 'allowed.' While this is desirable for
your file transfers, it might very well make the telnet/vt users a
triffle peeved ;-)

Of course, in this case, 'truth' is a relative thing. For example, if
you 'know' that you never get a burst of traffic through your router
greater that N packets, you might want to configure that many buffers
so as to avoid retransmissions. However, that value of N is not only
difficult to determine, it is also unlikely to remain static. 

As congestion controlled TCP's are becomming all the rage ;-),
configuring fewer buffers is probably a good thing - the TCP's will
still try to use 'all' the bandwidth/buffers, but you won't allow them
to build-up such an enormous delay. File transfers go through, and
interactive goes through.

Of course, tuning the relative bandwidths given each is a further, related
matter - perhaps some info on how OS schedulers go about sharing a CPU
amongst processes would be enlightening ;-) Then we could think of all
those bits in the IP header(s) as specifying 'process priorities' on a
pkt/pkt basis...

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | HP-UX   Networking   Performance
| \_/   \_/    Hewlett-Packard  Co.   | "It's so fast, that _______" ;-)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply