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

David Borman <dab@weston.borman.com> Thu, 22 May 2014 21:13 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 DA9A31A02DE for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 14:13:02 -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 WaCcGfMtwinO for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 14:13:00 -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 4A33A1A0381 for <tcpm@ietf.org>; Thu, 22 May 2014 14:13:00 -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 s4MLCl5h006582 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 22 May 2014 16:12:47 -0500 (CDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: David Borman <dab@weston.borman.com>
In-Reply-To: <537E3ACD.5000308@isi.edu>
Date: Thu, 22 May 2014 16:12:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1AD79820-22C1-4500-84D1-1383F264D68C@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>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/lspvzOwoL-r8E3efnUgYZTlbbao
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
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: Thu, 22 May 2014 21:13:03 -0000

On May 22, 2014, at 12:58 PM, Joe Touch <touch@isi.edu> wrote:

>> 2) However, I think the main problem is that many important cases will
>> need as large or larger TCP option space on the SYN as on non-SYNs.
> 
> Oh, I certainly agree with this. The point of this proposal is twofold:
> 
> 	a) (primary) to put to bed the notion that 'there is a way'
> 	to extend SYN option space without contaminating connections to
> 	legacy hosts

Add to that "without adding any additional packet exchanges."  That’s really the issue.  This can be done, within the existing TCP processing, but at the cost of an additional RTT, which everyone tries to avoid.  The receiver could respond to the initial SYN with another SYN, which *can* take advantage of an extended option space because it now knows that the other side supports EDO.  The originator incurs an additional RTT before it can send data (2 vs 1 RTT), the receiver has no delay for when it can send data (1.5 RTT).

Besides the additional RTT for the originator, the biggest problem with this would be all those blasted firewalls that would drop the returning SYN-only responses.  The other way to do this is that when the SYN/ACK comes back indicating that the other side supports EDO, then the originator sends another SYN with the expanded option space.  That has a cost of a full RTT in both directions.


But the issue still remains the same: for that initial SYN packet, with no a priori knowledge, there is no way to extend the option space and maintain 100% backwards compatibility.

			-David Borman