Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02
John Leslie <john@jlc.net> Fri, 26 September 2014 14:50 UTC
Return-Path: <john@jlc.net>
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 92C7C1A8943 for <tcpm@ietfa.amsl.com>; Fri, 26 Sep 2014 07:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level:
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 FRC6O2wnHz7B for <tcpm@ietfa.amsl.com>; Fri, 26 Sep 2014 07:50:40 -0700 (PDT)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4F01A893C for <tcpm@ietf.org>; Fri, 26 Sep 2014 07:50:39 -0700 (PDT)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 7110EC94C0; Fri, 26 Sep 2014 10:50:37 -0400 (EDT)
Date: Fri, 26 Sep 2014 10:50:37 -0400
From: John Leslie <john@jlc.net>
To: Bob Briscoe <bob.briscoe@bt.com>
Message-ID: <20140926145037.GA82183@verdi>
References: <201409222045.s8MKjZdD002071@bagheera.jungle.bt.co.uk> <542344DA.9020905@isi.edu> <201409250956.s8P9uae9013452@bagheera.jungle.bt.co.uk> <alpine.OSX.2.00.1409251716260.69041@ayourtch-mac> <201409251842.s8PIgUdQ015414@bagheera.jungle.bt.co.uk> <alpine.OSX.2.00.1409260049040.69041@ayourtch-mac> <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201409260957.s8Q9vmEd018560@bagheera.jungle.bt.co.uk>
User-Agent: Mutt/1.4.1i
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/LT7zAasVOW_dhyKxf3OMvQMA3W8
Cc: tcpm IETF list <tcpm@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02
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: Fri, 26 Sep 2014 14:50:42 -0000
Alas, I haven't found time to completely read any of these drafts; but I think an overview would be valuable... Bob Briscoe <bob.briscoe@bt.com> wrote: >... > To be absolutely clear: > a) SYN-EOS OOB client sends a SYN and an OOB segment to complement > it, using same src & dst ports. The OOB segment has SYN=0, ACK=0 and > the seqno is the same as the ISN of the SYN. This is draft-touch-tcpm-tcp-syn-ext-opt. Two packets are sent: one is a SYN; the other isn't. > b) SYN-EOS DS client sends 2 complementary SYNs, using same dst port, > but different src ports and different ISNs. This is also draft-touch-tcpm-syn-ext-opt. Two packets are sent: both are SYNs. Joe asks us to work out which approach is better. > c) syn-op-sis client sends 2 alternative SYNs, using same dst port, > but different src ports and different ISNs. This is draft-briscoe-tcpm-syn-op-sis. One packet is sent, but Bob expects a totally separate packet to be sent proposing a separate connection, and only one of these connections will completely open. > a & b use the word 'complement', which means an upgraded server needs > to have received both segments to start an upgraded connection. I agree with Bob here. > c uses the word 'alternative', which means a server can start a > connection when it receives either, and the upgraded handshake only > completes if it's an upgraded server. Likewise... And I note that there's no _need_ to specify anything about the overlap between the two proposed connections. I like this a lot better, because I never trust that two packets will always reach the same endpoint. Meddleboxes and muddleboxes are too common and too varied in their world-views. I'd like to remind folks of two other drafts: - draft-ietf-tcpm-fastopen "allows data to be carried in the SYN" packet. Something like this is inevitable; and _will_ put application-layer data in the inital SYN (to reduce experienced latency). - draft-nishida-tcpm-apaws "can provide protection against old duplicates" without using timestamps. (Timestamps will eat up ten bytes in _every_ packet.) This should reduce the demand for option space in the SYN. ==== Hopefully I don't need to draw attention to draft-touch-tcpm-edo. This seems to be moving towards consensus on how to increase the option space on every packet _after_ the initial SYN. Thus, in most cases, for today's traffic there is little need to worry about extending the option space in the initial SYN. There seems to be plenty of time to experiment... >>Probably the best way to decide is to implement both, get them in >>parallel into the olde wilde internets and see what sticks better! > > Before going to the trouble of implementation, some middlebox > traversal testing of the proposed packet formats might weed out the > field. I have a suspicion that the OOB segment won't get very far in > many cases - it's unlikely that all firewalls and intrusion detection > systems will allow the unusual ACK=0, SYN=0 and the same seqno as the SYN. I agree with Bob that we don't need formal Experimental status to test how often an OOB packet will fail to pass a middlebox. For any Experimental-status document, I recommend: - that the various on-the-wire formats be kept as similar as possible; - that any acknowledgment of extra option space in an initial SYN include a checksum or hash of the extra options to ensure that both ends have the same view of what options have been signaled; - that any timing questions be specifically explored as part of the experiment. (This includes _whether_ there should be any overlap between the experimental SYN and the legacy SYN.) - that an explicit allocation of one (or more, possibly) dedicated option number be requested from IANA. ==== IMHO, Bob's SYN-U cases are best condensed into a single format where the SYN sender explicitly notes the position in the payload to be occupied by additional TCP options, and guarantees that no application- layer data will follow these. The receiving endpoint would search for the extra options whether or not it found the SYN-U option in the initial SYN, and reply including a checksum/hash of the options it found. (The receiving endpoint MUST find some confirmation that these options were intended, or _it_ bears the responsibility to reverse any action on the extended options and pass the payload where it otherwise would have gone.) I'm not sure this entire middlebox-transit idea is worth the trouble; but it probably deserves to be an optional part of the experiment. The SYN-U sender MUST deal with the danger of its additional options being passed to the application as data. For legacy receivers it can do this by aborting before the end of the three-way handshake. But there must be coordination with tcpm-fastopen to protect against such data being passed to the application before the SYN-U sender can abort. (This is not a trivial consideration!) I believe that much deserves to be settled _before_ tcpm-fastopen is published as an RFC. (NB that document currently has been approved for publication, but is waiting on a Point-Raised writeup.) The fastopen mechanism calls for the SYN sender to request a Fast Open Cookie, which the SYN receiver will generate and return in the SYN-ACK. In a _future_ connection, the SYN sender can send that cookie, and all payload data will go to the application _before_ the three-way handshake completes. Thus there is no way to use both fastopen and SYN-U in the same connection. This is unfortunate!!! (Note that fastopen will be Experimental; and deficiencies can be fixed before it reaches Proposed Standard: it's just best to consider overlaps like this before the RFC is published.) ==== The question of separating payload data to go to the application from extended TCP options clearly requires action by the SYN receiver. This is fairly simple if the SYN sender can ensure that _none_ of the payload data should go to the application (and thus not use fastopen at all): of course the connection must still be aborted if the SYN receiver doesn't acknowledge separating out the extended options. IMHO, the SYN sender should never use SYN-U unless extra option space in the SYN is needed; and it's probably better to never use SYN-U for connections where latency of setup is the over-riding factor. But YMMV. I wonder whether such overlap is worth the trouble to try to design into the protocol. -- John Leslie <john@jlc.net>
- [tcpm] More TCP option space in a SYN: draft-bris… Bob Briscoe
- Re: [tcpm] draft-briscoe-tcpm-syn-op-sis-02 John Leslie
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Zimmermann, Alexander
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Andrew Yourtchenko
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Andrew Yourtchenko
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Andrew Yourtchenko
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Andrew Yourtchenko
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Andrew Yourtchenko
- Re: [tcpm] More TCP option space in a SYN: draft-… John Leslie
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… John Leslie
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… John Leslie
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… John Leslie
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Joe Touch
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe
- Re: [tcpm] More TCP option space in a SYN: draft-… Scharf, Michael (Michael)
- Re: [tcpm] More TCP option space in a SYN: draft-… John Leslie
- Re: [tcpm] More TCP option space in a SYN: draft-… Bob Briscoe