Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!hubcap!ncrcae!ncr-sd!hp-sdd!ucsdhub!esosun!seismo!uunet!cos!howard
From: howard@cos.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP performance limitations
Message-ID: <458@cos.COM>
Date: Fri, 2-Oct-87 09:04:59 EDT
Article-I.D.: cos.458
Posted: Fri Oct  2 09:04:59 1987
Date-Received: Sat, 3-Oct-87 09:12:52 EDT
References: <8709290008.AA00477@ucbvax.Berkeley.EDU> <2922@ames.arpa>
Organization: Corporation for Open Systems, McLean, VA
Lines: 51
Summary: SNA TG window control mechanism

In article <2922@ames.arpa>, lamaster@pioneer.arpa (Hugh LaMaster) writes:
> In article <8709290008.AA00477@ucbvax.Berkeley.EDU> AUERBACH@CSL.SRI.COM (Karl Auerbach) writes:
> 
> >Someone asked me today what are the performance limits on a TCP connection.
> >The situation he posited was on in which there are no intervening
> :
> >resources in the hosts, and low noise.  It was further posited that
> 
> An interesting question. It depends on HOW low noise your connection is.
> Because of acknowledgement and retransmission requirements, the faster the
> link, the lower noise it has to be to maintain a high delivered fraction of
> the raw channel speed.  This is in addition to the question of the interaction
> of acknowledgement delay and window size, which some have mentioned, and which
> is also a big problem.  To realize the high bandwidth in practice requires
> host software smart enough to adaptively distinguish between a high bandwidth
> low noise channel, and something like Arpanet, and adjust its behavior
> appropriately to either situation.  Offhand, I am not sure how to do this.
> Anybody have any ideas?

     A mechanism for implementing adaption to noise could be
   drawn from the SNA technique for varying the window size
   on FID4 Transmission Groups.  Essentially, a given path
   starts out with a default window size, which can be changed
   by nodes along the way based on their buffer availability
   status.  For severe congestion, a node can reset the
   window size to 1, for minor congestion, a node can decrease
   the window size BY 1.  If a node feels it can handle more
   traffic, it can also set a bit indicating it would like
   to increase the window size by 1.

     While this mechanism is intended more for congestion control
   adaption rather than error adaption, I did use it in a
   protocol for a network management system which used both
   dedicated and dial lines for control channels.  I started
   with a value assumed for dial lines, and gradually increased
   the frame and window size based on modified error-free 
   interval length.  By "modified," I mean that I kept an error
   counter which was decremented and incremented differently
   for retransmissions and for successfully transmitted sequences --
   retransmissions decremented the error-free interval counter
   by a lesser value than did long sequences of successful
   transmission.  This modification protected the frame and
   window sizes from radical changes due to error bursts.
   In general, those sizes were changed occasionally by 1,
   at thresholds determined by simulation, to give the
   best mixture of parameters for the encountered error conditions.  
-- 
-- howard(Howard C. Berkowitz) @cos.com
 {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [ofc] (703) 998-5017 [home]
DISCLAIMER:  I explicitly identify COS official positions.