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

Joe Touch <touch@isi.edu> Thu, 22 May 2014 17:59 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 19FF11A0216 for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 10:59:15 -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 MS7N_xZ_BRlv for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 10:59:13 -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 594AE1A026C for <tcpm@ietf.org>; Thu, 22 May 2014 10:59:13 -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 s4MHwbWn010442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 10:58:37 -0700 (PDT)
Message-ID: <537E3ACD.5000308@isi.edu>
Date: Thu, 22 May 2014 10:58:37 -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: 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>
In-Reply-To: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
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/TzgTKU_4Tkc3tDB0MMvfydiDxOY
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 17:59:15 -0000

Hi, Bob,

On 5/22/2014 10:10 AM, Bob Briscoe wrote:
> Joe,
>
> Returning to the question of adoption, we have to address the question
> of why previous attempts to do this have failed. I don't believe it is
> as simple as that they tried to include options on SYNs, so all we have
> to do is avoid the SYN problem.

There haven't been any I can recall that didn't either focus on SYN 
space extension or include it as a key component.

> 1) There is obviously the re-segmentation problem, which Olivier/Costin
> have usefully highlighted, and I agree an optional checksum would at
> least detect this.

An optional checksum would help protect TCP from such "attacks" - 
re-segmentation isn't supported, and already breaks a number of existing 
TCP features (TCP-AO, TCP MD5, ACK clocking requirements, etc.).

> 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.

> The option space pressure for all the following (except SACK) is at
> least as critical for the SYN as for non-SYN segments:
> * SACK          (SYN << non-SYN)
> * MPTCP (SYN > non-SYN - typically)
> * Timestamp     (SYN = non-SYN)
> * Window scale  (SYN > non-SYN)
> * TCP-AO        (SYN = non-SYN)
> * TFO init      (SYN << non-SYN - but no use without TFO resume as well)
> * TFO resume    (SYN >> non-SYN)
>
> Given the above list, if bigger TCP options are not available for SYNs,
> is a critical mass really going to be persuaded that it is worth the
> effort of implementing, deploying, debugging, supporting, etc?

Maybe never; I don't know. This isn't a "build it and they will come" 
proposal; it's intended to document the 'negative' about SYN extension 
primarily. The extension of non-SYN is intended primarily to show how it 
can trivially be done, not to argue that it's a great thing to do it.

> And we
> need a critical mass, because until EDO is deployed at both ends it does
> nothing, so early implementers have to work on faith.
>
> Admittedly, EDO is partly trying to make space for future options and
> partly trying to solve a problem we already have with existing options.
> So, I admit that the relative size of existing options is not the whole
> story. However, even new options have to fit with the existing ones.
>
> 3) The EDO draft implies that it is provably impossible to increase the
> option space on a SYN.

It states it, with the condition of not contaminating connections to 
legacy TCPs.

> A couple of ways have been proposed to solve this
> problem:
> * LOIC <draft-yourtchenko-tcp-loic-00> that sends two parallel SYNs; a
> regular one and one with a longer TCP option space AND a newly defined
> checksum calculation, so that it will be discarded by legacy TCPs.

The problem happens when the non-legacy endpoint gets the legacy SYN 
first - or only. There's no good way to do support dual-stack without 
incurring huge delay penalties waiting for a SYN with the new feature.

> * An out-of-band control channel, e.g. <draft-paasch-mptcp-control-stream>

That won't work for the first SYN to a new endpoint, which is always 
where the problem exists. Subsequent SYNs can always be affected by 
persistent state, if desired.

> Much earlier in this thread, you dismissed the latter, wrongly I believe:
>
>> >At 16:00 25/04/2014, Zimmermann, Alexander wrote:
>> >> * Sec 4:
>> >>    - Should we mention „draft-paasch-mptcp-control-stream“ here?
>> >
>> > I don't think so, any more than mentioning FTP's control channel. In
>> both cases, a separate data channel is used for control info. The
>> MPTCP approach isn't applicable to individual TCP connections - it
>> only works in MPTCP because the group of connections is co-associated.
>
> This seems to miss the point that there could be a whole class of
> solutions where we create an associated connection, precisely in order
> to add a control channel of unlimited size to one (or more) data
> channels. This brings its own problems, not least it loses the intrinsic
> security binding when control and data are in the same segment. So, I
> wouldn't separate off a control channel if we were starting from
> scratch. But it's probably the most promising approach, given we have to
> add a carbuncle to a wart.
>
> In fact there are some similarities between parallel SYNs and parallel
> channels.

The problematic case is first-contact. All other contacts - either 
within a single connection or with subsequent connections can be handled 
in any number of ways - a control channel, state that's left-behind, etc.

> 4) Finally, the EDO draft cites <draft-ananth-tcpm-tcpoptext-00> as if
> it is just another solution. It's not. It's actually a very useful
> survey of all the previous attempts to solve this problem, including a
> useful enumeration of the problems that have to be surmounted.

I'll correct that.

> The arguments on this thread show that we don't agree on the problem
> space. So, I suggest we adopt Anatha's draft, and as we develop it, we
> agree on the problem we are trying to solve first. Boring, but
> apparently necessary.

I don't agree with much of the content of that doc regarding the 
enumeration of requirements. I don't agree that this is a useful place 
to start, nor did the WG when it was first proposed AFAIR.

Joe