Subject: Re: Connection Establishment

From: David Borman <[email-masked]>
Date: Wed, 6 Feb 2002 08:55:28 -0600 (CST)

Sebastian,

> From: Sebastian Zimmermann <[email-masked]>
> To: [email-masked]
> Subject: Connection Establishment
...
> 2nd case: the server does the active open and sends data
>
>     - server sends SYN
>     - client sends SYN+ACK
>     - server sends ACK
>
> And now the question:
>
>     May the server send the data already with the final ACK of the 
> connection establishment (piggyback),

Yes.  It can even include the FIN if it all fits in the packet.

> or must it send two packets (ACK and data),

No.

> or must it wait for the clients ACK of the ACK (and then send 
> data)?

ACK packets are never acked.  If the ACK gets lost, the other
side will retransmit the data (SYN) to elicit another ACK.

> Thanks for your help
>    Sebastian

			-David Borman, [email-masked]

---

From: Bob Braden <[email-masked]>
Date: Wed, 6 Feb 2002 16:51:18 GMT

*> Hello,
  *> 
  *> I would like to ask for some help with correct connection establishment:
  *> 
  *> 1st case: the client does the active open, server sends data (payload)
  *> 
  *>     - client sends SYN
  *>     - server sends SYN-ACK
  *>     - client sends ACK
  *>     - server sends data
  *> 
  *> I assume, that this is correct. But what happens in the
  *> 
  *> 2nd case: the server does the active open and sends data
  *> 
  *>     - server sends SYN
  *>     - client sends SYN+ACK
  *>     - server sends ACK
  *> 
  *> And now the question:
  *> 
  *>     May the server send the data already with the final ACK of the 
  *> connection establishment (piggyback), or must it send two packets (ACK 
  *> and data), or must it wait for the clients ACK of the ACK (and then send 
  *> data)?
  *> 
  *> Thanks for your help
  *> 
  *>    Sebastian
  *> 

Without even reading your question, I can tell you that anything
in the TCP state diagram that is not forbidden is allowed, and
packetization may be done in any way the implementor desires.
(But of course some strategies work better than others.)

Bob Braden

---

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 6 Feb 2002 14:03:42 -0500

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.