RE: Connection Establishment

["Naidu, Venkata" <[e-mail]>]

Jeremy:

-> >   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?

  Actually there are more interoperability issues here. An intelligent
  TCP implementation can make an educated guess. In other words,
  	- Include as much data application gives in the 
        first connect request message
      - If it didn't get through, then in subsequent re-tries
	  either don't include any data or include less data
	  (with exponential back off with limited tries is one solution)

  This is because, in order to interoperate with different TCP
  implementations. Other end has either:
	- no support of piggyback data reception support, or
	- short of window (you don't know)

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

   That means, TCP should track type of applications (actually
   connections). TCP should know before hand that - when it receives
   data with a connect request, it SHOULD give only if the application
   has all the above requirements/constraints.

-> 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.

   Yes! I agree... this is a very good optimization for some
   applications

--Venkata Naidu


This e-mail and any attachments are confidential. If you are not the
intended recipient, please notify us immediately by reply e-mail and then
delete this message from your system. Do not copy this e-mail or any
attachment, use the contents for any purposes, or disclose the contents to
any other person: to do so could be a breach of confidence.