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

Joe Touch <touch@isi.edu> Thu, 22 May 2014 21:06 UTC

Return-Path: <touch@isi.edu>
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 7601A1A0349 for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 14:06:11 -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 2Zkt0OmsYbUC for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 14:06:10 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5611A032F for <tcpm@ietf.org>; Thu, 22 May 2014 14:06:10 -0700 (PDT)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s4ML5iRh012990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 14:05:44 -0700 (PDT)
Message-ID: <537E66A7.4080907@isi.edu>
Date: Thu, 22 May 2014 14:05:43 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Wesley Eddy <wes@mti-systems.com>, 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> <537E48CE.8040704@mti-systems.com>
In-Reply-To: <537E48CE.8040704@mti-systems.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/C1z1q_8OrhwrII45b-pihfsKaIc
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:06:11 -0000


On 5/22/2014 11:58 AM, Wesley Eddy wrote:
> 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),

Well, AFAICT we've also known for a long time that it's basically 
impossible when needed - i.e., to new endpoints, without impacting 
legacy endpoints (i.e., making their connections to new systems slow or 
misinterpreting option info as user data).

Yes, there are a few other potential solutions that need to be discussed 
as non-viable, but IMO that's an important part of this doc.

At the very least, even if it's not provably impossible, the obvious 
solutions don't work and it's harder than it looks.

Joe