Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!MATHOM.CISCO.COM!BILLW
From: BILLW@MATHOM.CISCO.COM (William "Chops" Westfield)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Why Fewer Buffers (was Changing TCP port)
Message-ID: <12682495520.11.BILLW@mathom.cisco.com>
Date: 3 May 91 21:08:37 GMT
References: <PIRARD@vm1.ulg.ac.be>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 46


    >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 ;-)

Well, not if it's a good (Van Jacobson Slow start) TCP.  In that case, it
will try to source packets at a continuous bandwidth equal to the bandwidth
of the path, rather than sending out bursts of data at a bandwidth equal
to the local interface.  See Van's paper on congestion avoidance.


    I still wonder about cisco's reason....  On the other, I don't think they
    believe many hosts respond to source quench...

Even hosts that don't listen to source quench have been known to slow down
their transmissions in the face of lost packets.  In fact, it is a matter of
current debate whether sending a source quench has any advantage over merely
dropping the packet (and it has the obvious disadvantage of generating extra
traffic on an already congested path).


    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.

Avoiding duplicate datagram thrashing (DDT?) is THE major reason for using
smaller queues.  This is unfortunately still very prevalent in TCP/IP, even
though the algorithms have been developed to help prevent it.  Many other
protocols are much dumber, and don't even have any facility for slowing
down in the presence of congestion.  If you believe that ANY queue with
an average size of greater than one represents a congested link, the actual
queue sizes on routers don't have to be very big.


    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.

Sure, given infinite CPU resources on the routers, one can do anything...

Bill Westfield
cisco Systems.
-------