Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
<philip.eardley@bt.com> Wed, 18 July 2018 15:47 UTC
Return-Path: <philip.eardley@bt.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC411311AB for <multipathtcp@ietfa.amsl.com>; Wed, 18 Jul 2018 08:47:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 1YveTXH-wyx2 for <multipathtcp@ietfa.amsl.com>; Wed, 18 Jul 2018 08:47:48 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C3A13118F for <multipathtcp@ietf.org>; Wed, 18 Jul 2018 08:47:47 -0700 (PDT)
Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 18 Jul 2018 16:47:41 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 18 Jul 2018 16:47:44 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Wed, 18 Jul 2018 16:47:44 +0100
From: philip.eardley@bt.com
To: cpaasch@apple.com
CC: multipathtcp@ietf.org
Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAFZGvbgABoZzJQACL4mAAAAvROIA==
Date: Wed, 18 Jul 2018 15:47:43 +0000
Message-ID: <ab236e37db2343d6bb11b5b1f7759ea6@rew09926dag03b.domain1.systemhost.net>
References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <f64af1576d994d888a7b82fb75dc8318@rew09926dag03b.domain1.systemhost.net> <20180715201445.GU1471@MacBook-Pro-19.local> <b90520f39bea4fc9a5bf22b011ec4ac0@rew09926dag03b.domain1.systemhost.net> <20180718144528.GO1471@MacBook-Pro-19.local>
In-Reply-To: <20180718144528.GO1471@MacBook-Pro-19.local>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.216.161.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/0XQ2sQGBla6ojorlz-WzEKO2eF8>
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2018 15:47:53 -0000
Something that needs fixing which Christoph and I just noticed during a chat at the IETF: S3.7 on Fallback has <<Note that this rule essentially prohibits the sending of data on the third packet of an MP_CAPABLE or MP_JOIN handshake, since both that option and a DSS cannot fit in TCP option space.>> this needs a mod now data is allowed on the third packet. ..... > > [phil] ok - if I get it right the motivation for the change in the MP_CAPABLE protocol exchange starts from the observation that option space is most constrained in the SYN, so reducing the size of MP_CAPABLE in the SYN allows other TCP options to be used in the SYn. As a consequence of this decision, Host A doesn't know that Host B has learnt its key, unless the ACK is sent reliably. The story actually unfolded the other way around. We identified a need for reliable key-exchanges when talking to stateless servers. Based on this we made the key-exchange reliable in the third ACK/first data segment. Upon this, we realized that we can gain space in the SYN. Thus, the motivation for the change was the need for the reliable MP_CAPABLE. > I think it would be useful to tweak the figure in Section 2.1 - just to say the ack is delivered reliably. Incorporating it into the figure seems tricky to me. I changed the first sentence to mention data as well: "... initial ACK (and data) packets also ..." [phil2] the figure in S2.1 (ie in the Operation Overview section) should be modified. As it is compulsory to send the MP_CAPABLE ACK message on the first data packet. Sending MP_CAPABLE ACK without data is done if host A doesn't have data to send, but you still have to send ACK later with the first data. Whereas the natural way to interpret the current fig in S2.1 is that the Ack is sent once. ...... I have another comment. In Section 3.1, there is: If receiving a message with the 'B' flag set to 1, and this is not understood, then this SYN MUST be silently ignored. I suggest to change this to "... then the MP_CAPABLE in this SYN MUST be silently ignored.". Otherwise, hosts setting the B-bit to test for a feature-capability will incur a SYN-retransmission timeout, which is a huge latency penalty. Please let me know if that is acceptable. [phil2] fine by me - please make it clear this means fallback to TCP (as in similar text for other cases where we fallback)
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Yoshifumi Nishida
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- [multipathtcp] WG Last Call for draft-ietf-mptcp-… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Alan Ford
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- [multipathtcp] FW: WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Alan Ford
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Christoph Paasch
- [multipathtcp] WG Last Call for draft-ietf-mptcp-… philip.eardley
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… Rahul Arvind Jadhav
- Re: [multipathtcp] WG Last Call for draft-ietf-mp… philip.eardley