Subject: RE: Connection Establishment

From: Jeremy Harris - Network Service Providers Division <[email-masked]>
Date: Wed, 6 Feb 2002 18:23:23 +0000 (GMT)

[email-masked] 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		[email-masked]

---

From: David Nicol <[email-masked]>
Date: Thu, 07 Feb 2002 15:39:43 -0600

> Jeremy Harris           [email-masked]

fascinating -- you're suggesting HTTP over datagrams.  Or at least
acting like datagrams when all you really want is a datagram.  You
can dispense with the connection when all you want is a datagram.

-- 
           David L Nicol, humble system administrator (816) 235 1187
   "... to regret something you haven't done.  So the next time ..."

---

From: Henk Langeveld - NL <[email-masked]>
Date: Fri, 08 Feb 2002 01:10:44 +0100

> can dispense with the connection when all you want is a datagram.

This is beginning to look like the DNS approach:  Just use udp
on the first attempt, and revert to tcp when the result would be
too large?

Frankly, given that one of the conditions given was sufficient
resistance/defence against DoS attacks,  I doubt this will ever
escape the lab.  A proper defence against DoS attacks is miserly
conduct with your resources, until you've established at least
some validity in the request - this will require a round trip from
server to client.

If you're going to allow initial datagrams carrying data, you'll
have to limit the size of that data, possibly using the same
constraints as the DNS udp/tcp switch referred to above.  You might
be thinking of a specific application for this web-service, where
you'd control the network stack of both client and server *and*
the network in between.  Then you've got your value-add network,
with your own application protocol - why use http?

Henk