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
- [tcpm] Fwd: New Version Notification for draft-to… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Pasi Sarolahti
- Re: [tcpm] New Version Notification for draft-tou… Wesley Eddy
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… Yoshifumi Nishida
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Scharf, Michael (Michael)
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… Olivier Bonaventure
- Re: [tcpm] New Version Notification for draft-tou… Scharf, Michael (Michael)
- Re: [tcpm] New Version Notification for draft-tou… Costin Raiciu
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Wesley Eddy
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Costin Raiciu
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Scheffenegger, Richard
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Wesley Eddy
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… David Borman
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… David Borman
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- [tcpm] timestamp options (was Re: New Version Not… Eggert, Lars
- Re: [tcpm] timestamp options (was Re: New Version… Brian Trammell
- Re: [tcpm] timestamp options (was Re: New Version… Scharf, Michael (Michael)
- Re: [tcpm] timestamp options (was Re: New Version… Scheffenegger, Richard
- Re: [tcpm] timestamp options (was Re: New Version… Scharf, Michael (Michael)
- Re: [tcpm] timestamp options (was Re: New Version… Scheffenegger, Richard
- Re: [tcpm] timestamp options (was Re: New Version… Scharf, Michael (Michael)
- Re: [tcpm] timestamp options (was Re: New Version… Yoshifumi Nishida
- Re: [tcpm] timestamp options (was Re: New Version… Joe Touch
- Re: [tcpm] timestamp options (was Re: New Version… Yoshifumi Nishida
- Re: [tcpm] timestamp options (was Re: New Version… Scheffenegger, Richard
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… Christoph Paasch
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… Bob Briscoe
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Olivier Bonaventure
- Re: [tcpm] New Version Notification for draft-tou… Olivier Bonaventure
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] timestamp options (was Re: New Version… Joe Touch
- Re: [tcpm] timestamp options (was Re: New Version… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… John Leslie
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Olivier Bonaventure
- Re: [tcpm] New Version Notification for draft-tou… Olivier Bonaventure
- [tcpm] More TCP option space on SYNs Bob Briscoe
- Re: [tcpm] More TCP option space on SYNs Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- Re: [tcpm] New Version Notification for draft-tou… Joe Touch
- [tcpm] SYN extension using ACK=0 data packets Bob Briscoe
- Re: [tcpm] SYN extension using ACK=0 data packets Joe Touch
- Re: [tcpm] More TCP option space on SYNs Bob Briscoe
- Re: [tcpm] SYN extension using ACK=0 data packets Bob Briscoe
- Re: [tcpm] timestamp options (was Re: New Version… Yoshifumi Nishida
- Re: [tcpm] timestamp options (was Re: New Version… Joe Touch
- Re: [tcpm] timestamp options (was Re: New Version… Mark Allman
- Re: [tcpm] timestamp options (was Re: New Version… Mark Allman
- Re: [tcpm] timestamp options (was Re: New Version… Scharf, Michael (Michael)
- Re: [tcpm] timestamp options (was Re: New Version… Joe Touch
- Re: [tcpm] timestamp options (was Re: New Version… Joe Touch
- Re: [tcpm] timestamp options (was Re: New Version… Scharf, Michael (Michael)
- Re: [tcpm] timestamp options (was Re: New Version… Mark Allman
- Re: [tcpm] timestamp options (was Re: New Version… Mark Allman
- Re: [tcpm] timestamp options (was Re: New Version… Joe Touch
- Re: [tcpm] timestamp options (was Re: New Version… Yoshifumi Nishida
- Re: [tcpm] timestamp options (was Re: New Version… Yuchung Cheng
- Re: [tcpm] timestamp options (was Re: New Version… Mark Allman
- Re: [tcpm] timestamp options (was Re: New Version… Yuchung Cheng
- Re: [tcpm] More TCP option space on SYNs Martin Duke
- Re: [tcpm] More TCP option space on SYNs Joe Touch