[tcpm] More TCP options

Stefanos Harhalakis <v13@v13.gr> Wed, 16 July 2008 17:46 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8F75A3A698C; Wed, 16 Jul 2008 10:46:06 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 059323A67B5 for <tcpm@core3.amsl.com>; Wed, 16 Jul 2008 10:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id LPzs-AjLrYy4 for <tcpm@core3.amsl.com>; Wed, 16 Jul 2008 10:46:01 -0700 (PDT)
Received: from mx-out.forthnet.gr (mx-out.forthnet.gr []) by core3.amsl.com (Postfix) with ESMTP id A72293A698C for <tcpm@ietf.org>; Wed, 16 Jul 2008 10:46:00 -0700 (PDT)
Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr []) by mx-out-04.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6GHkTRF006582 for <tcpm@ietf.org>; Wed, 16 Jul 2008 20:46:29 +0300
Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr []) by mx-av-04.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6GHkTpo025167 for <tcpm@ietf.org>; Wed, 16 Jul 2008 20:46:29 +0300
Received: from hell.hell.gr (adsl43-134.lsf.forthnet.gr []) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id m6GHkPad001121 for <tcpm@ietf.org>; Wed, 16 Jul 2008 20:46:26 +0300
Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=v13@v13.gr; spf=neutral
Authentication-Results: MX-IN-01.forthnet.gr header.from=v13@v13.gr; sender-id=neutral
From: Stefanos Harhalakis <v13@v13.gr>
To: tcpm@ietf.org
Date: Wed, 16 Jul 2008 20:46:24 +0300
User-Agent: KMail/1.9.9
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200807162046.24361.v13@v13.gr>
Subject: [tcpm] More TCP options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

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'. I propose that long options be implemented as an 
intermediate layer between the existing TCP and the data. Imagine something 
like this:

| TCP Header | Extended TCP Header  (Long Options) | Data |

Then, middleboxes (NAT boxes) will be unaffected as long they don't re-pack 
data (is there such a possibility?).

The initial option negotiation problem will be solved by:
* Permitting cookies to do their job as there will be no extra options in the 
SYNACK segment.
* Allowing extra options to be negotiated by data segments. (A modification to 
existing TCP semantics).

After a successful "extended header" negotiation, all TCP segments should 
contain an option that indicates the size of the included extend header. This 
may be 0 for no such options. Having this in mind it will be possible to 
allow more options to be negotiated using data segments (most probably the 
first segment). A way for reliably performing such a handshake is also 

I believe that we should have in mind what we would like to have in 10 years 
from now (and not tomorrow) and that something like the above will be an 
absolute requirement. Providing such a common infrastructure to TCP will 
allow most TCP implementations to become compatible in (lets say) N years 
from now and be able to "survive" for M (M>>N) years more, without loosing 
backward compatibility.

Nonsense ? Already discussed ? 
tcpm mailing list