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

Wesley Eddy <wes@mti-systems.com> Mon, 05 May 2014 15:50 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 CBFD11A0298 for <tcpm@ietfa.amsl.com>; Mon, 5 May 2014 08:50:18 -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 9jBqjkxj3pcJ for <tcpm@ietfa.amsl.com>; Mon, 5 May 2014 08:50:17 -0700 (PDT)
Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id CB1FC1A00C6 for <tcpm@ietf.org>; Mon, 5 May 2014 08:50:16 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.206]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s45FoB1r011700 for <tcpm@ietf.org>; Mon, 5 May 2014 11:50:11 -0400
Received: (qmail 11545 invoked by uid 0); 5 May 2014 15:50:11 -0000
X-TCPREMOTEIP: 107.46.91.152
X-Authenticated-UID: wes@mti-systems.com
Received: from unknown (HELO ?192.168.43.65?) (wes@mti-systems.com@107.46.91.152) by 0 with ESMTPA; 5 May 2014 15:50:10 -0000
Message-ID: <5367B32C.3080702@mti-systems.com>
Date: Mon, 05 May 2014 11:50:04 -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.4.0
MIME-Version: 1.0
To: John Leslie <john@jlc.net>, Costin Raiciu <c.raiciu@cs.ucl.ac.uk>
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> <536548D7.5030802@uclouvain.be> <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk> <20140505144109.GQ44329@verdi>
In-Reply-To: <20140505144109.GQ44329@verdi>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XRO00gnLQ8F7TfaHZiSN57_sKOA
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: Mon, 05 May 2014 15:50:19 -0000

On 5/5/2014 10:41 AM, John Leslie wrote:
>> However, most NATs have a passive FTP mode - which means they will
>> > look through the TCP payload for the host's IP address and rewrite
>> > with their own. 
>
>    (That's one of the reasons I prefer to have "Data Offset" be a clearly
> invalid value whenever it is overridden by EDO: any middlebox will then
> have fair warning that it is clueless.)
> 


I think I agree.  IMHO, the tradeoff comes down to whether it's more
desirable for the middlebox to end up doing something violent like:

- dropping the segment
- resetting the TCP connection
- generating an ICMP
- crashing

versus just doing something to the segments which the receiver can
detect and possibly work-around with greater size and complexity in
the mechanism itself.

It ends up being a matter of transition and whether we really
expect offending nodes to be found and fixed over time, and can
stand some deployment hassles and complaints in the meantime.
If not, then the design needs to be a bit more complicated forever
in order to accommodate today's legacy.

If there are significant advantages to being able to use long
options that relate to real business problems, then I think the
legacy won't be as much of a problem, but don't really know.

-- 
Wes Eddy
MTI Systems