Re: [multipathtcp] AD review is coming

Alan Ford <> Mon, 15 April 2019 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AABF120099; Mon, 15 Apr 2019 09:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XZIgNRmE0G40; Mon, 15 Apr 2019 09:55:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7C8A12000F; Mon, 15 Apr 2019 09:55:17 -0700 (PDT)
Received: by with SMTP id s15so22852397wra.12; Mon, 15 Apr 2019 09:55:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hTaDfKp0DapHs8XfiDZ3PtaQCAxLgMWFjzUmzLVBcew=; b=QH3g5EiYPxe/tpvIL3PUYpMLSPB+OX///ynLI1AO/NMXQEZcBVZjyAKiiVGL1RKKje kQeMpVuNiWKnYds8nPezQccwUlVm6X2qfS49blUlmqAJEEUxIr4kT6wQVcau5pustC+0 tyojKJDZ/ezIJljaNUSpHIru+uhfJCUFeYGhjWV57iymgUMUPmtssgvrlbOw+atPdEoM 86l2HqaOWmw9SXCjUgkT0cxK7Kzwinh4RFgCm//EhgnL01LRPw3YUfZSvdCV/oHWjP1H Fn+oozC+J8928L1/WPl55k5Oxa5jZusV4hWwig8+SXZ42n70+zzqaxttHuMRxLDumO5E ULmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hTaDfKp0DapHs8XfiDZ3PtaQCAxLgMWFjzUmzLVBcew=; b=Oy0zWh2p/HM/nSYsIrDHxiWtYpCQRs+/n4nxLqWrR+75CLiWpc1Mk4YCOhKzHVqVW0 5djFQy5bb8oTgEt2jDSdeqJUNSgDUJt+PhQ37xQiI+ZlSZT3E7X12LdVFGa5D9yC83hf nJWK/Fm4Dkceru8rr3f4DHoFphxnyi29NNEfD46g30xRTS/xiPHb/v4r91n6NIiaKN+V rt5OJl8WKd97TRRGCOzL4ktxIrtCucCis+Arh6qlsfDXOF4gdWpC3FhOGBaY6PXH1ktN kgXKMYX1pp0JnFeNduQEwYhxVmWcQcmtGxDDRTCL/sw6CNHdAnoRqh5ioxvGQ0IicxSF FyUw==
X-Gm-Message-State: APjAAAUMfrKSqGQvQ0uSKKgJVNfBNP1OX4wcWuYWDTFw7yxWhq8/A1Hu ASc20GvyeYQivC7BacE2G9AUH8zI
X-Google-Smtp-Source: APXvYqw8P6Fm4vAe0V3RqvKHHi8OZDlJGQwE6/GM61zNCrUZba41tO1c/ifqtFxMd6E8Qxs7IYSG2g==
X-Received: by 2002:a5d:68cd:: with SMTP id p13mr12696815wrw.22.1555347316221; Mon, 15 Apr 2019 09:55:16 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q8sm21058663wmq.35.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Apr 2019 09:55:15 -0700 (PDT)
From: Alan Ford <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_332D42D5-381E-4A98-A96E-25083BF8E909"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 15 Apr 2019 17:55:11 +0100
In-Reply-To: <>
To: Mirja Kuehlewind <>
References: <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [multipathtcp] AD review is coming
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2019 16:55:19 -0000

Hi Mirja,

To be clear, you are looking for some rationale in the draft text as well? The technical discussion of the fallback process is given in Section 3.1:
   The MP_CAPABLE exchange in this specification (v1) is different to
   that specified in v0 [RFC6824].  If a host supports multiple versions
   of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the
   highest version number it supports.  In return, in its MP_CAPABLE
   option, the receiver will signal the version number it wishes to use,
   which MUST be equal to or lower than the version number indicated in
   the initial MP_CAPABLE.  There is a caveat though with respect to
   this version negotiation with old listeners that only support v0.  A
   listener that supports v0 expects that the MP_CAPABLE option in the
   SYN-segment includes the initiator's key.  If the initiator however
   already upgraded to v1, it won't include the key in the SYN-segment.
   Thus, the listener will ignore the MP_CAPABLE of this SYN-segment and
   reply with a SYN/ACK that does not include an MP_CAPABLE, thus
   leading to a fallback to regular TCP.  An initiator MAY cache this
   information about a peer and for future connections, MAY choose to
   attempt using MPTCP v0, if supported, before recording the host as
   not supporting MPTCP.
But you would like to see some discussion mentioning the migration from Experimental to Proposed Standard? And the benefits it brings? Would that cover it?

Many thanks,

> On 12 Apr 2019, at 17:40, Mirja Kuehlewind <> wrote:
> Hi authors, hi shepherd/Phil,
> Just wanted to quickly let you know that I’ve started the IETF last call just now in order to hopefully get this document on the telechat in 3 weeks. 
> I’ve not finished my AD review completely but I am nearly done and convinced that this doc is ready to start IETF last call. So far I have only some editorial or smallish comments and nits which I will send in detail beginning of next week and can be address during or after IETF last call.
> Only one request for now (mostly with an eye on the IESG evaluation): The draft says that changes are made which are not backward compatible (see sec 3.1). That’s fine, however, it would be good to also explain a little bit in the draft as well as in the shepherd write up (!) why this is okay. My understanding is that in case of a v0 server the connection will “just" fall-back to non-MPTCP capable and that this is acceptable in current deployment situation. Please confirm and at least update the write-up accordingly as soon as possible!
> Thanks!
> Mirja