Re: [tcpm] TCP Long Options

"Caitlin Bestler" <> Mon, 07 July 2008 19:45 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 638BE3A6B1C; Mon, 7 Jul 2008 12:45:32 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B11A53A6B21 for <>; Mon, 7 Jul 2008 12:45:22 -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 6q50rvenhoNK for <>; Mon, 7 Jul 2008 12:45:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5947D3A6B13 for <>; Mon, 7 Jul 2008 12:45:16 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 07 Jul 2008 15:45:27 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter>
In-Reply-To: <>
Thread-Topic: [tcpm] TCP Long Options
Thread-Index: AcjbqDxYikw807+KSPevT7OwgdvH3AEuH1OwAAIJBsA=
References: <><><> <>
From: Caitlin Bestler <>
To: "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>, Adam Langley <>, Joe Touch <>
Subject: Re: [tcpm] TCP Long 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Wesley Eddy wrote:
> I guess the real problem was that the TCPM group didn't ever get
> consensus that working on any long options mechanism was important,
> so it never got done as a WG item, and it couldn't be done as an
> independent submission RFC because TCP is a core protocol.  Thus,
> 4 years later, it is still not done, and I still get email every
> few months from people that stumble upon the draft and want to use
> it to enable some other experimental modification that requires a
> really long option or two.  I think this is what happened with Adam.
> He was working on another project, ran across the previous version
> of the TCP Long Options draft, and discovered it was what he had been
> reinventing.
> In my personal opinion, it's a good idea to have some way to do
> long options (any way, not necessarily even this draft) that's
> at least published Experimental (off by default), simply because
> different groups of people keep thinking they need long options.  I
> think that's the point that the WG didn't have consensus on in the
> past, and may or may not still lack.

The functionality sought with TCP "long options" are already provided
with SCTP. The only valid reason cited for not using SCTP for these
type of new applications is lack of support from middle-boxes.

Any TCP enhancement that does not preserve transparency to existing
software and hardware will face all of the problems of SCTP, and
probably with fewer benefits.

In addition to the middle-box issue that is always cited, there is
a special issue with changing the syntax of TCP options that is in
the hosts themselves - any form of header/data separation done in
existing software or hardware could be broken. This is especially
true for LRO/LSO (Large Receive/Send Offload).

I strongly suspect that any encoding that provided more option space
would prove inherently incompatible with one or more existing middle
boxes, host stacks and/or NICs. If such a feature merely provides
SOCK_STREAM service between two enhancement-aware endpoints, then
why not simply map SOCK_STREAM to SCTP at both ends and leave TCP

tcpm mailing list