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

Wesley Eddy <wes@mti-systems.com> Thu, 22 May 2014 18:58 UTC

Return-Path: <wes@mti-systems.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 139831A02D5 for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 11:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 ATrGp6N6TnNc for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 11:58:39 -0700 (PDT)
Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC231A02C9 for <tcpm@ietf.org>; Thu, 22 May 2014 11:58:30 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s4MIwSU3030500 for <tcpm@ietf.org>; Thu, 22 May 2014 14:58:28 -0400
Received: (qmail 17197 invoked by uid 0); 22 May 2014 18:58:28 -0000
X-TCPREMOTEIP: 107.48.65.33
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.48.65.33) by 0 with ESMTPA; 22 May 2014 18:58:27 -0000
Message-ID: <537E48CE.8040704@mti-systems.com>
Date: Thu, 22 May 2014 14:58:22 -0400
From: Wesley Eddy <wes@mti-systems.com>
Organization: MTI Systems
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, Bob Briscoe <bob.briscoe@bt.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>
In-Reply-To: <537E3ACD.5000308@isi.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/ljI_vWl4TEtlR00-tg3r8g5lHWI
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 18:58:43 -0000

On 5/22/2014 1:58 PM, Joe Touch 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
> 
>     b) (secondary) to do the only extension possible - post-SYN.


I agree with this.  In my view, we actually have had consensus
for a long time that extending the SYN is "really hard" (requiring
some creativity), whereas extending the options space on other
packets can be done quite a bit more trivially.

So, the problem is decomposed into 2 parts; the harder part and
the easier part.  EDO is leaving the harder part alone for now;
although it may ultimately be the more useful one to solve.  I
don't see this as a problem with EDO or reason not to do it ...
any future solution for SYNs may differ substantially, but would
seem like it should not impact how options are extended on other
segments.


-- 
Wes Eddy
MTI Systems