IETF Logo Mail Archive

Re: [tcpm] TCP Long Options

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 07 July 2008 20:34 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 [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACCE28C1D8; Mon, 7 Jul 2008 13:34:39 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72BA428C1E1 for <tcpm@core3.amsl.com>; Mon, 7 Jul 2008 13:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm6sPCdtWrgI for <tcpm@core3.amsl.com>; Mon, 7 Jul 2008 13:34:37 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 76A2228C1D8 for <tcpm@ietf.org>; 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 sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2008 20:30:51 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m67KUptR010637; Mon, 7 Jul 2008 13:30:51 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m67KUpGN012074; Mon, 7 Jul 2008 20:30:51 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com 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: <0C53DCFB700D144284A584F54711EC58056FDCA4@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] TCP Long Options
Thread-Index: AcjbqDxYikw807+KSPevT7OwgdvH3AEuH1OwAAIJBsAAAWSLQA==
References: <396556a20807010949i6c6c1d16g41c74e2f78414a92@mail.gmail.com><486A6777.80809@isi.edu><396556a20807011128v27796016k81204b84e78fc25a@mail.gmail.com><B5A5E01F9387F4409E67604C0257C71E220E3A@NDJSEVS25A.ndc.nasa.gov> <78C9135A3D2ECE4B8162EBDCE82CAD7703DC2C9B@nekter>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Caitlin Bestler <Caitlin.Bestler@neterion.com>, "Eddy, Wesley M. (GRC-RCN0)[VZ]" <wesley.m.eddy@nasa.gov>, Adam Langley <agl@imperialviolet.org>, Joe Touch <touch@isi.edu>
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; d=cisco.com; i=ananth@cisco.com; 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; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: tcpm@ietf.org
Subject: Re: [tcpm] TCP Long 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

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

<snip>

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

$0.02,
-Anantha
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email