Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

David Borman <dab@weston.borman.com> Fri, 23 May 2014 16:33 UTC

Return-Path: <dab@weston.borman.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DE31A06DA for <tcpm@ietfa.amsl.com>; Fri, 23 May 2014 09:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmeE7XN6Ux1K for <tcpm@ietfa.amsl.com>; Fri, 23 May 2014 09:33:47 -0700 (PDT)
Received: from frantic.weston.borman.com (frantic.weston.borman.com [70.57.156.33]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0241A00E5 for <tcpm@ietf.org>; Fri, 23 May 2014 09:33:40 -0700 (PDT)
Received: from local-42.weston.borman.com (local-42.weston.borman.com [192.168.1.42]) by frantic.weston.borman.com (8.14.7/8.14.7) with ESMTP id s4NGXYBd020093 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 23 May 2014 11:33:34 -0500 (CDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: David Borman <dab@weston.borman.com>
In-Reply-To: <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk>
Date: Fri, 23 May 2014 11:33:34 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6391C448-A917-4E66-9B73-CB840B193FD7@weston.borman.com>
References: <20140425221257.12559.43206.idtracker@ietfa.amsl.com> <2586_1398464386_535ADF82_2586_915_1_535ADF56.9050106@isi.edu> <CF8D8E25-E435-4199-8FD6-3F7066447292@iki.fi> <5363AF84.8090701@mti-systems.com> <5363B397.8090009@isi.edu> <CAO249yeyr5q21-=e6p5azwULOh1_jUsniZ6YPcDYd69av8MMYw@mail.gmail.com> <DCC98F94-EA74-4AAA-94AE-E399A405AF13@isi.edu> <655C07320163294895BBADA28372AF5D2CFE36@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140503122950.GM44329@verdi> <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu.alcatel-lucent.com> <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk> <537E3ACD.5000308@isi.edu> <1AD79820-22C1-4500-84D1-1383F264D68C@weston.borman.com> <201405231213.s4NCDa5P005525@bagheera.jungle.bt.co.uk>
To: Bob Briscoe <bob.briscoe@bt.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/HY76rIqk38vc_o4AVylOSjJimIQ
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Fri, 23 May 2014 16:33:49 -0000

Hi Bob,

On May 23, 2014, at 7:13 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:

> David,
> 
> There is certainly no need for an additional RTT.

Oh, there will always be proposals for ways to avoid the additional RTT, but at what cost?  A parallel control channel is a lot of complexity if its only purpose is to get more option space for a single, initial SYN packet.


> Let me propose a couple of concrete strawmen (concrete men?) to show this. I'm not claiming these are novel. I know Joe and others think that we've seen enough of attempts to extend the TCP options on the SYN, but Joe should know that when he claims something is impossible, he wakes sleeping dragons in people like me.

What is impossible is to expand the option space in the initial SYN packet and maintain 100% backwards compatibility with the following restrictions:
   1) No additional packets are sent, just the initial SYN
   2) There is no a priori knowledge as to whether or not the remote host understands expanded option space.

Every proposal that maintains 100% backwards compatibility has to send additional data in other packets in some form.  A parallel data channel, a second SYN, whatever, they all require additional data in separate packets.

			-David