Subject: Re: [net-next-2.6 PATCH v6 4/7 RFC] TCPCT part 1d: define TCP cookie option, extend existing struct's

From: William Allen Simpson <[email-masked]>
Date: Mon, 16 Nov 2009 17:09:17 -0500

Eric Dumazet wrote:
> I am a bit uneasy on this patch, since apparently you have infrastructure
> to send DATA payload on SYN, but I thought it was an optional part of your 'RFC'
> and as such, being implemented later ?
> 
There is nothing yet in this patch series to send data with a SYN.  Back in
early October, David required that the various s_data and cookie structures
be compressed and consolidated.  So, for the client side, the cookie_*
fields are filled and the s_data_* fields are zero (ignored), while the
server side can have both filled.

Moreover, *this* patch does nothing other than allocate and deallocate the
structure, zero filled by kzalloc().

SYN data will be implemented (much) later.

> I remember a previous remark from David that our skb queues would not contain
> DATA on SYN packets...
> 
I haven't seen anything by David, but there's an existing comment in
tcp_input.c at the place where SYN data will be added later:

			/* Now we have several options: In theory there is
			 * nothing else in the frame. KA9Q has an option to
			 * send data with the syn, BSD accepts data with the
			 * syn up to the [to be] advertised window and
			 * Solaris 2.1 gives you a protocol error. For now
			 * we just ignore it, that fits the spec precisely
			 * and avoids incompatibilities. It would be nice in
			 * future to drop through and process the data.

As you know, there's an old Linux t/tcp patch series out there to add SYN
data.  I'm also working with my KA9Q and BSD sources.