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

Joe Touch <> Thu, 09 December 2010 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0973B3A688C; Thu, 9 Dec 2010 10:24:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gJuuDQo2hNtZ; Thu, 9 Dec 2010 10:24:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 168CC3A6958; Thu, 9 Dec 2010 10:24:09 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id oB9IOrWW023688 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 9 Dec 2010 10:25:03 -0800 (PST)
Message-ID: <>
Date: Thu, 09 Dec 2010 10:24:51 -0800
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Pete McCann <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>, "" <>
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Dec 2010 18:24:10 -0000

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.

(if there are others, can others post?)