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

Bob Briscoe <bob.briscoe@bt.com> Thu, 22 May 2014 17:10 UTC

Return-Path: <bob.briscoe@bt.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 C46041A0252 for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 10:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.252
X-Spam-Level:
X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 RzugH0AziBIS for <tcpm@ietfa.amsl.com>; Thu, 22 May 2014 10:10:40 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C2771A0270 for <tcpm@ietf.org>; Thu, 22 May 2014 10:10:39 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 22 May 2014 18:10:36 +0100
Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 22 May 2014 18:10:36 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.3.181.6; Thu, 22 May 2014 18:10:35 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s4MHAY4S002037; Thu, 22 May 2014 18:10:34 +0100
Message-ID: <201405221710.s4MHAY4S002037@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 22 May 2014 18:10:33 +0100
To: Joe Touch <touch@isi.edu>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <655C07320163294895BBADA28372AF5D2D009E@FR712WXCHMBA15.zeu. alcatel-lucent.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>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/mx8wpzwlM_GKxERkwzh9eVPUzLk
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:10:42 -0000

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.

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.

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.

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? 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. 
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.
* An out-of-band control channel, e.g. <draft-paasch-mptcp-control-stream>

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.

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.

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.


You could precis this whole email as "Necessity 
and impossibility are the mothers of invention".

Regards


Bob


________________________________________________________________
Bob Briscoe,                                                  BT