IETF Logo Mail Archive

Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

<philip.eardley@bt.com> Thu, 19 July 2018 20:20 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 CEE71130E2A for <multipathtcp@ietfa.amsl.com>; Thu, 19 Jul 2018 13:20:06 -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 h_MOI9HSFbX3 for <multipathtcp@ietfa.amsl.com>; Thu, 19 Jul 2018 13:20:05 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88A8130DC9 for <multipathtcp@ietf.org>; Thu, 19 Jul 2018 13:20:04 -0700 (PDT)
Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 19 Jul 2018 21:20:02 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 19 Jul 2018 21:20:00 +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; Thu, 19 Jul 2018 21:20:00 +0100
From: philip.eardley@bt.com
To: alan.ford@gmail.com
CC: cpaasch@apple.com, multipathtcp@ietf.org
Thread-Topic: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAFZGvbgABoZzJQAF8qoYAAA9oCQA==
Date: Thu, 19 Jul 2018 20:20:00 +0000
Message-ID: <ca486ad0db8147d9bba055e2ee8de20b@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> <BC7D1FE4-4E78-400C-9EEB-21EA7165F28B@gmail.com>
In-Reply-To: <BC7D1FE4-4E78-400C-9EEB-21EA7165F28B@gmail.com>
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/WY1OgNKJZbqfYsEzFbaWxNf9Ce0>
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: Thu, 19 Jul 2018 20:20:07 -0000

I'll leave it to you & Christoph to work on some clearer text

-----Original Message-----
From: Alan Ford [mailto:alan.ford@gmail.com] 
Sent: 19 July 2018 15:29
To: Eardley,PL,Philip,TUD1 R <philip.eardley@bt.com>
Cc: cpaasch@apple.com; multipathtcp@ietf.org
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

Hi Phil,

Catching up on these comments, re this:

> On 18 Jul 2018, at 00:30, philip.eardley@bt.com wrote:
> 
> << Note that new subflows MUST NOT be established
>   (using the process documented in Section 3.2) until a Data Sequence
>   Signal (DSS) option has been successfully received across the path
>   (as documented in Section 3.3).>>
> In the case where A sends data first, then the MP-CAPABLE is sent instead of the DSS. Does the text quoted mean that new subflows are not allowed (until an actual DSS is sent) or are they allowed because DSS has kind of been inferred?

I think the text still holds. We need a DSS to be received (as a DATA ACK) in order to know the path is fully MPTCP capable.

Regards,
Alan

v2.23.0 | Report a Bug | By Email