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

Joe Touch <touch@isi.edu> Mon, 05 May 2014 15:57 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 23E011A03BE for <tcpm@ietfa.amsl.com>; Mon, 5 May 2014 08:57:04 -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 NS1HXdBjhwJp for <tcpm@ietfa.amsl.com>; Mon, 5 May 2014 08:57:01 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C78311A03BB for <tcpm@ietf.org>; Mon, 5 May 2014 08:57:01 -0700 (PDT)
Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s45FuDva007423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 May 2014 08:56:16 -0700 (PDT)
Message-ID: <5367B4A0.4090600@isi.edu>
Date: Mon, 05 May 2014 08:56:16 -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: Costin Raiciu <c.raiciu@cs.ucl.ac.uk>, Olivier.Bonaventure@uclouvain.be
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>
In-Reply-To: <68C69A33-3733-48FB-AED6-E1DBC121C5B7@cs.ucl.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; 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/EpBk7BcqGiD99mPDv52Xym3IHsc
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: Mon, 05 May 2014 15:57:04 -0000


On 5/5/2014 12:49 AM, Costin Raiciu wrote:
> I'd like to add to what Olivier has said.
>
> One question I had about this draft is whether the options included
> in the EDO are supposed to be carrying sequence numbers or not. Two
> options:
>
> 1. they carry sequence numbers: in this case we are changing the
> semantics of options in TCP, sending them reliably, orderly and
> subject to flow control.

We're not doing that any more than the options in existing segments 
within the existing Data Offset are so covered.

The option isn't buried in the data stream - this was considered for 
MPTCP, but rejected, for some of the reasons you mention.

So EDO option space ought to be used the same way - with the same 
limitations (or not) of existing option space.

...
> Another thing: the draft says that NAT will work with EDO. 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. With EDO, the NAT could be messing up options placed in
> EDO space in the payload. To avoid this you need a checksum, as
> Olivier says.

See my response to Oliver's issue on this. Such a NAT ought to have 
either dropped the EDO in the initial SYN or dropped the SYN completely.

Joe