Re: [tcpm] More TCP options

"Caitlin Bestler" <> Wed, 16 July 2008 18:41 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 846293A67EB; Wed, 16 Jul 2008 11:41:19 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AADDF3A63EC for <>; Wed, 16 Jul 2008 11:41:17 -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=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TaCk+716geeO for <>; Wed, 16 Jul 2008 11:41:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD31B3A67EB for <>; Wed, 16 Jul 2008 11:41:16 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 16 Jul 2008 14:41:46 -0400
Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD7703E6760F@nekter>
In-Reply-To: <>
Thread-Topic: [tcpm] More TCP options
Thread-Index: Acjna/D3nuiYGfhhQziQ3b3TTcnc9QABv7ww
References: <>
From: Caitlin Bestler <>
To: Stefanos Harhalakis <>,
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefanos Harhalakis wrote:

> Upon exchanging and agreeing on this option, both sides will be able
> 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
> pack data (is there such a possibility?).

Very definitely. See RFC 5044 on what RDMA had to do to work around
these problems.

The bottom line is that the TCP Data Stream is a stream, and no
offload NIC or middle-box is obligated to understand it as having
any other structure.

The best you can do is to create an endpoint agreement that they
will exchange certain information in the payload, and only proceed
farther if they are in agreement.

Something like that might be possible as an endpoint solution, and
still be exercised by the TCP stacks themselves.

tcpm mailing list