Re: [nbs] [Int-area] New draft related to name-based sockets

[Joe Touch <[e-mail]>]

On 12/8/2010 7:43 PM, Pete McCann wrote:
> Hi, Joe,
>
> Thanks - can you elucidate or send a pointer to the issues with
> putting data in the SYN?  Are you worried that some middleboxes
> will have problems and drop such packets?

There was a discussion a few years back on this list on various ways to 
extend the space for TCP options, which are most limited in SYNs.

The general problem is backward compatibility; that data cannot be 
assumed to be ignored by endpoints that don't support the option. TCP is 
required to ignore unknown options, and when it does, it would start a 
connection and interpret the options as data.

An additional problem is that many implementations simply discard SYN 
data, to reduce the amount of state until the connection handshake finishes.

I'm speaking most specifically of issues with putting options in the SYN 
data; there are other problems with putting options in the payload data.

Further, since this option can't be rejected by a legacy endpoint per 
se, the initiator needs to then stop the connection after receiving the 
SYN-ACK. Doing so without leaving state on the other end requires a RST, 
but that has other potential problems (RST gets lost, other end resends 
the SYN-ACK), etc.

So the key questions are:
- can TCP option space be extended without negatively impacting legacy 
implementations, in a way that isn't equivalent to creating a new 
transport anyway?

> I'd be particularly interested if you can point me at some of these
> prior proposals.

http://tools.ietf.org/html/draft-eddy-tcp-loo-03

http://tools.ietf.org/html/draft-kohler-tcpm-extopt-00

http://tools.ietf.org/html/draft-allman-tcpx2-hack-00

(if there are others, can others post?)

Joe