Re: [tcpm] TCP Long Options

"Anantha Ramaiah (ananth)" <> Mon, 07 July 2008 20:34 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id DACCE28C1D8; Mon, 7 Jul 2008 13:34:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72BA428C1E1 for <>; Mon, 7 Jul 2008 13:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tm6sPCdtWrgI for <>; Mon, 7 Jul 2008 13:34:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 76A2228C1D8 for <>; Mon, 7 Jul 2008 13:34:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.30,318,1212364800"; d="scan'208";a="63357019"
Received: from ([]) by with ESMTP; 07 Jul 2008 20:30:51 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id m67KUptR010637; Mon, 7 Jul 2008 13:30:51 -0700
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id m67KUpGN012074; Mon, 7 Jul 2008 20:30:51 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Jul 2008 13:30:51 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 07 Jul 2008 13:29:48 -0700
Message-ID: <>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter>
Thread-Topic: [tcpm] TCP Long Options
Thread-Index: AcjbqDxYikw807+KSPevT7OwgdvH3AEuH1OwAAIJBsAAAWSLQA==
References: <><><><> <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter>
From: "Anantha Ramaiah (ananth)" <>
To: Caitlin Bestler <>, "Eddy, Wesley M. (GRC-RCN0)[VZ]" <>, Adam Langley <>, Joe Touch <>
X-OriginalArrivalTime: 07 Jul 2008 20:30:51.0138 (UTC) FILETIME=[58D51E20:01C8E070]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1445; t=1215462651; x=1216326651; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[tcpm]=20TCP=20Long=20Options |Sender:=20; bh=E+Ubb2eLKbH2yGgEJ75vjXBvFoMVRglJv/wP8r8yYHk=; b=OgffQ28UABVGMtNfmE0pujb1defOoRVfY8iYxWMKgmRJKRinXaXd+5tGuA RFAGQ0Yw290OoxP2BifBFnS7RAxNgflB1ihPB4RVDaEGakiBGuIIpsodA3dI Ifp1+DQmbo;
Authentication-Results: sj-dkim-3;; dkim=pass ( sig from verified; );
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

> > 
> 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.

I have to dis-agree here. There are planty of TCP applications that
wouldn't simply migrate to SCTP for many reasons. This is somewhat
similar to the "IPv4 to IPv6 transition, NAT's" etc., Hence I would be
very careful to use this sort of reasoning.

> 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.

Well, are you saying that the proposed enhancements wouldn't work well
with middleboxes? Again, that shouldn't stop from having enhancements
made to TCP. IMO.


> 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 alone?

Easier said than done. The issue here is that the existing TCP
applications need support for long TCP options, so asking them to
migrate to SCTP may be ok, but doesn't sound practical.

tcpm mailing list