Re: [tcpm] More TCP options

Joe Touch <touch@ISI.EDU> Wed, 16 July 2008 21:21 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 988F33A6A08; Wed, 16 Jul 2008 14:21:43 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 737DD3A68AD for <>; Wed, 16 Jul 2008 14:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rw4uOu5vWfDh for <>; Wed, 16 Jul 2008 14:21:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 810863A6A06 for <>; Wed, 16 Jul 2008 14:21:08 -0700 (PDT)
Received: from [] ( []) by (8.13.8/8.13.8) with ESMTP id m6GLH5e2017535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Jul 2008 14:17:09 -0700 (PDT)
Message-ID: <>
Date: Wed, 16 Jul 2008 14:17:04 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird (Windows/20080421)
MIME-Version: 1.0
To: Stefanos Harhalakis <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [tcpm] More TCP options
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============2022031596=="

Stefanos Harhalakis wrote:
> Hello there,
> AFAICS there is clearly a need for more options space in TCP (especially in a 
> way to extend option negotiation). Even though current needs may be satisfied 
> with workarounds, it is clear that a more generic approach will be needed.
> I suggest that we find a backwards compatible solution that would allow TCP to 
> become extensible again.
> I dare to propose one such approach:
> Add one (final) TCP option that would be negotiated during the initial 
> handshake. This option will eventually initiate a kind of TCPv2 communication 
> that may one day in the future become the de-facto standard.
> Upon exchanging and agreeing on this option, both sides will be able to 
> support 'long options'.

This is equivalent to a required TCP option. There's no such thing; if 
the other side doesn't support the option, it will return a SYN/ACK 
(granted, without the appropriate response).

The trouble is that the only solution is to RST that connection. That 
means that the new TCP is NOT backward compatible. There's no such 
thing, as a result. You might as well pick another protocol number, at 
which point you can redefine the protocol fields however you like.

> Nonsense ? Already discussed ? 

I do think we've been around this block before; it led to Mark Allman's 
"double everything" proposal. If it's worth discussing in Dublin, it 
might be useful, but I encourage others to review the archives on this 


tcpm mailing list