Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!VM1.ULG.AC.BE!PIRARD
From: PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Why Fewer Buffers (was Changing TCP port)
Message-ID: <9105031114.AA05297@ucbvax.Berkeley.EDU>
Date: 3 May 91 09:12:30 GMT
References: <hpda!hpcupt1!hpindwa!raj@UCBVAX.BERKELEY.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of Liege (Belgium), SEGI (Computing Center)
Lines: 35

On Mon, 11 Feb 91 02:33:35 GMT Rick Jones said:
>>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 ;-)
>[...]

I still wonder about cisco's reason.
On one hand, they seem to have gone the TOS-faking way with heuristics for
response time. On the other, I don't think they believe many hosts respond to
source quench and throwing interactive packets on top of a full queue doesn't
help much, does it (but organizing queues by datagram size may help a bit).
The only reason I can think of for a small amount of buffers is avoiding
the duplicate datagrams thrashing plague (hence queue proportional to max
throughput), but a mixed limit seems coarse, per host seems unfair to
multiuser machines and per TCP connection incomplete and badly layered.

Finally, on grounds of what came in must go, I wonder if the most drastically
effective heuristics wouldn't be to detect and drop duplicate queued packets,
with the excuse of unreliability for rare mistakes.

Layers, layers...

Andr'e PIRARD         SEGI, Univ. de Li`ege        139.165 IP coordinator
B26 - Sart Tilman     B-4000 Li`ege 1 (Belgium)           +32 (41) 564932
pirard@vm1.ulg.ac.be  alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU