Path: utzoo!attcan!uunet!husc6!ukma!rutgers!ucsd!ucbvax!NSSDCA.GSFC.NASA.GOV!NETMGR
From: NETMGR@NSSDCA.GSFC.NASA.GOV (SPAN Network Info Center  286-7251, 301)
Newsgroups: comp.protocols.tcp-ip
Subject: Forwarding a bounced mail message.
Message-ID: <880914121034.2040104D322@nssdca.GSFC.NASA.GOV>
Date: 14 Sep 88 17:10:34 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 78

From:	NCF::SYSTEM       30-AUG-1988 15:02
To:	POSTMASTER
Subj:	Mail error notification

Cannot deliver message to following recipients:
CLYNN@g.BBN.COM.
   Reason: EXOS Mail error:  Connection timed out

*** Original message follows: ***

Received: by nssdca id <202008E6051@nssdca.GSFC.NASA.GOV> ;
       Tue, 30 Aug 88 11:37:31 EST
Date: Tue, 30 Aug 88 11:37:14 EST
From: postmaster@nssdca.GSFC.NASA.GOV
Subject:  Re: Call queueing
To: CLYNN@g.BBN.COM
X-VMS-Mail-To: EXOS%"<CLYNN@G.BBN.COM>"
Message-ID: <880830113714.202008E6051@nssdca.GSFC.NASA.GOV>

 *** VMS error in delivery mail, error message follows *** 

EXOS Mail server: delivery error: %MAIL-E-OPENOUT, error opening 
NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
EXOS Mail server: delivery error: -RMS-E-CRE, ACP file create failed_ADM_US
ER:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
EXOS Mail server: delivery error: -SYSTEM-F-EXDISKQUOTA, disk quota exceededR:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
EXOS Mail server: delivery error: 
%MAIL-E-OPENOUT, error opening NCF_ADM_USER:[PETERS.MAIL]MAIL$0004009181D1D9D7.MAI; as output
-RMS-E-CRE, ACP file create failed
-SYSTEM-F-EXDISKQUOTA, disk quota exceeded

 *** Original message follows *** 

From : CLYNN@G.BBN.COM
Subject:  Re: Call queueing

Return-path: <tcp-ip-RELAY@SRI-NIC.ARPA>
Received: from SRI-NIC.ARPA by nssdca.GSFC.NASA.GOV
          id 202006E5002 ; Tue, 30 Aug 88 11:35:12 EST
Received:  from G.BBN.COM by SRI-NIC.ARPA with TCP; Mon, 29 Aug 88 08:19:55 PDT
Date:  29 Aug 1988 11:18-EDT
Sender:  CLYNN@G.BBN.COM
To:  tcp-ip-request@SRI-NIC.ARPA
Cc:  tcp-ip@SRI-NIC.ARPA
Message-ID:  <[G.BBN.COM]29-Aug-88 11:18:41.CLYNN>
In-Reply-To:  <626@root44.co.uk>

Jeremy,
	As John pointed out, the call queueing is used to reduce the
probability that a SYN arrives during a window where there is no listening
connection to bind it to, thus causing a RESET to be returned.  Queueing
can only reduce it, since it is always possible for there to be more
arriving SYNs than there are remaining free queue slots.  However, I reguard
specifying the size to the kernel to be more for the purpose of "limiting"
resources (such as processes [from the forks] and cpu cycles) than for
"allocating" them.
	As with all implementations, tradeoffs have been made.  I feel that
one of the "minuses" with the BSD implementation is that not only does the
listen cause the arriving SYN to be accepted and bound to a new TCP connection
block, but that the protocol machine is also started.  Thus a connection may
proceed to the ESTABLISHED state and accept/ACKnowledge (usually 4K bytes of)
data before the application-level peer (process) is even created.  This
prevents the process from:
    1) examining the IP-address identity of the caller before deciding
       ACKnowledge the SYN vs. send a RESET,
          What if X were to place a "collect" call to such an implementation
          and send 4K data; then the receiver process start up and decides
          it doesn't want to accept the call.  Who pays for the 4K bytes?
          (The receiver COULD make the 4K available to the appliaction.)
    2) checking its routing tables and applying administratively specified
       per IP-address source routing, etc.,
    3) selecting initialization parters based on IP-level parameters such as
       TOS and options, or
           Maybe local system has a method for setting the TCP MSS (which
           the spec says has to be in the SYN packet).           
    4) specifying initial TCP-level options, etc.

Charlie