Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!VENERA.ISI.EDU!braden
From: braden@VENERA.ISI.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Reliable Datagram ??? Protocols
Message-ID: <9010311808.AA07256@braden.isi.edu>
Date: 31 Oct 90 18:08:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 61


	You're right:  RECEIVE calls are supposed to be queued until the connection
	reaches ESTABLISHED (RFC 793, pg 58).  The discussion of OPEN, SEND and
	RECEIVE in that section seems somewhat out of line with the requirement
	elsewhere in the RFC that TCPs accept data with the initial SYN, because
	it appears that the API specified in section 3.9 can't generate it (SENDs
	are queued until the connection reaches ESTABLISHED as well).

	I will raise this as an issue with the HR WG.  My own initial feeling
	is that the API's restriction is unnecessary, and could be relaxed at
	considerable benefit to the Internet...

	James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
	FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

James,

I believe that the API defined in RFC-793 was intended to describe
the MINIMUM set of capabilities required of an implementation; in
fact, there are weasel-words about that in the RFC.  Thus, it was
not intended to be a "restriction"; an implementation could go
beyond it, to include for example, a call: OPENandSEND(...).

I also believe, however, that the detailed protocol description
in RFC-793 is inconsistent in a number of little ways with the
5-packet minimum request-response exchange that TCP could in
principle provide:

    1.   SYN, req-data, FIN ----->  
    2.                   <--------- SYN, ACK
    3.   ACK -------->  (deliver data to application)  
    4.                   <---------  ACK, rep-data, FIN   
    5.   ACK -------->   

There are problems both in the state diagram and in the event
processing rules.  Although some of the early research TCP's could
handle this 5-packet exchange, the issue did not get a lot of attention
when the DoD put the heat on the research group to tie down the TCP
spec.  Maybe there is a job here for Host Requirements Man (leaps
tall buildings at a single bound, etc). 

Pardon me while I wax philosphical for a moment.

The early TCPs were all designed to implement "what the protocol meant"
(as Charlie Lynn can attest).  The words in RFC-793 were written later,
and getting them exactly right was (and is!) HARD.  Witness the Milspec
spectacle.  Implementors are still advised to implement what the
protocol means, not what the spec says.

It is arguably a defect of TCP as a protocol (and an advantage of TP4?)
that TCP is very subtle, and therefore it is complex and difficult to
describe in detail.  Writing an efficient and fully correct TCP ab
initio is still a great programming challenges, I believe (as I think
you will agree, James!)  I wonder of there are ANY fully correct
implementations of the (entire) TCP protocol in the world today?

Bob Braden