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

[Pete McCann <[e-mail]>]

Hi, Joe,

Thanks for the issue list and the pointers to drafts.

I agree that backwards compatibility is an issue, if we are blindly
opening connections to previously unknown peers.  However, in
the pickle packet framework, opening a connection would always
be preceded by a DNS lookup for the TXT record at
_pickle.host.example.com which, if present, would be an indication
that the peer supports the new extensions.  So, I think there is
little danger of running into the issues you cite.

You might say that this is equivalent to defining a new transport,
but I think it's important to keep the protocol number 6 because
that is what today's middleboxes will pass.

-Pete

On Thu, Dec 9, 2010 at 12:24 PM, Joe Touch <[e-mail]> wrote:
>
>
> 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
>