RE: Connection Establishment

[Jeremy Harris - Network Service Providers Division <[e-mail]>]

[e-mail] said:
>   As per TCP standard (not w.r.t. any API implementations, 
>   like sockets)
> 
>   Machine A initiates a connection to machine B.
>   A sends a segment with ISN x, chosen according
>   A's clock, and with SYN bit set to 1, this is the
>   connection request message.
> 	- the ACK flag is set to 0
> 	- this segment is still a regular TCP segment; it
> 	  can carry data too (piggyback 1)

I have implemented this; it works nicely.   However, the question
arises: how much data may be piggybacked on a SYN?  What window may
the sender assume?

>       - however, if it does contain data, machine B
>         cannot deliver the data to application until the
>         connection is successfully established

As a nonstandard extension to TCP, I propose that this restriction
can be relaxed in certain situations:

IF
- The TCP and next layer up ("ULP") are tightly-coupled (e.g. both in the
  kernel) and have a rich interface
- The ULP data consists of a request which
	- does not require much processing
	- does not modify any server state (bar stats counters, cache
	  state etc)
  ( thus making the "at-most-once" property of TCP unneeded )
- The receiver system can adequately defend itself against DOS attack

THEN
   the "piggyback 1" data can be delivered to the ULP.
   
Further, IF
- The ULP can respond with public data

THEN
   the "piggyback 2" can carry that response.
   

I believe that an HTTP GET which hits an in-kernel cache satisfies the
above constraints; the transaction can then be reduced to a minimum of
three packets.

Jeremy Harris		[e-mail]