[tcpm] Inner Option Space revised: inner-space-01

Bob Briscoe <bob.briscoe@bt.com> Mon, 27 October 2014 23:01 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 D87911A6F3A for <tcpm@ietfa.amsl.com>; Mon, 27 Oct 2014 16:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tyKP12EWLeCE for <tcpm@ietfa.amsl.com>; Mon, 27 Oct 2014 16:01:20 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457601A6F11 for <tcpm@ietf.org>; Mon, 27 Oct 2014 16:00:30 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR65-UKRD.bt.com (10.187.101.20) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 28 Oct 2014 03:18:18 +0000
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; Mon, 27 Oct 2014 23:00:24 +0000
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; Mon, 27 Oct 2014 23:00:22 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.109.38.168]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s9RN0Kx0017152 for <tcpm@ietf.org>; Mon, 27 Oct 2014 23:00:20 GMT
Message-ID: <201410272300.s9RN0Kx0017152@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 27 Oct 2014 23:00:20 +0000
To: tcpm IETF list <tcpm@ietf.org>
From: Bob Briscoe <bob.briscoe@bt.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/JrzY5UOOPECWi0fUGLezCsnkTY0
Subject: [tcpm] Inner Option Space revised: inner-space-01
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, 27 Oct 2014 23:01:25 -0000

TCPM folks,

I've posted a revision to:
"Inner Space for TCP Options"
<https://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01>

Thanks to the following for useful discussions (mostly off-list), 
whom I've added the Acknowledgements section:
Costin Raiciu, Marcelo Bagnulo Braun, Julian Chesterfield and Jaime 
Garcia, and of course the continuing discussions with Joe Touch.

       Technical changes:

       *  Corrected DO to 4 * DO (twice)
       *  Confirmed that receive window applies to Inner Options
       *  Generalised the cause of decryption/decompression from a
          previous TCP option to any previous control message
       *  Added requirement for a middlebox not to defer data on SYN
       *  Latency of dual handshake is worst of two
       *  Completed "Interaction with Pre-Existing TCP Implementations"
          section, covering other TCP variants, TCP in middleboxes and
          the TCP API.  Shifted some TCP options to Outer only, because
          of RWND deadlock problem
       *  Added two outstanding issues: i) ossifies reliable ordered
          delivery; ii) Ideally Outer in Inner.

       Editorial changes:

       *  Removed section on Echo TCP option to a separate I-D that is
          mandatory to implement for inner-space, and shifted some SYN
          flood discussion in Security Considerations
       *  Clarifications throughout
       *  Acknowledged more review comments

Cheers


Bob

>From: <internet-drafts@ietf.org>
>To: Bob Briscoe <bob.briscoe@bt.com>, "Bob J. Briscoe" <bob.briscoe@bt.com>
>Subject: New Version Notification for draft-briscoe-tcpm-inner-space-01.txt
>Date: Mon, 27 Oct 2014 12:07:17 -0700
>
>
>A new version of I-D, draft-briscoe-tcpm-inner-space-01.txt
>has been successfully submitted by Bob Briscoe and posted to the
>IETF repository.
>
>Name:           draft-briscoe-tcpm-inner-space
>Revision:       01
>Title:          Inner Space for TCP Options
>Document date:  2014-10-27
>Group:          Individual Submission
>Pages:          49
>URL: 
>http://www.ietf.org/internet-drafts/draft-briscoe-tcpm-inner-space-01.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-briscoe-tcpm-inner-space/
>Htmlized:       http://tools.ietf.org/html/draft-briscoe-tcpm-inner-space-01
>Diff: 
>http://www.ietf.org/rfcdiff?url2=draft-briscoe-tcpm-inner-space-01
>
>Abstract:
>    This document describes an experimental method to extend the limited
>    space for control options in every segment of a TCP connection.  It
>    can use a dual handshake so that, from the very first SYN segment,
>    extra option space can immediately start to be used optimistically.
>    At the same time a dual handshake prevents a legacy server from
>    getting confused and sending the control options to the application
>    as user-data.  The dual handshake is only one strategy - a single
>    handshake will usually suffice once deployment has got started.  The
>    protocol is designed to traverse most known middleboxes including
>    connection splitters, because it sits wholly within the TCP Data.  It
>    also provides reliable ordered delivery for control options.
>    Therefore, it should allow new TCP options to be introduced i) with
>    minimal middlebox traversal problems; ii) with incremental deployment
>    from legacy servers; iii) without an extra round of handshaking delay
>    iv) without having to provide its own loss recovery and ordering
>    mechanism and v) without arbitrary limits on available space.
>
> 
>
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

________________________________________________________________
Bob Briscoe,                                                  BT