[Gen-art] Gen-ART LC review of draft-ietf-mptcp-experience-06
Dan Romascanu <dromasca@gmail.com> Tue, 06 September 2016 16:18 UTC
Return-Path: <dromasca@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3F012B206 for <gen-art@ietfa.amsl.com>; Tue, 6 Sep 2016 09:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 kP_T8uHeS7dB for <gen-art@ietfa.amsl.com>; Tue, 6 Sep 2016 09:18:31 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE2F12B226 for <gen-art@ietf.org>; Tue, 6 Sep 2016 09:18:27 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id l2so223190209qkf.3 for <gen-art@ietf.org>; Tue, 06 Sep 2016 09:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=8oEU82ZVitBz4Ig2Bwfp5Is7/SICE7dzdyHbdHkAUH0=; b=Cc2laPIvyqJDvPqsovHIV8danofeDBuo4C9irwYiBbVlvP6bHJ2zJpnuMMz9Wqdmvi FyqShZUD8w+vlIkkEj6qMsrEGPVXcr38v3O0mtUKw2dOTKCs8rpkp71zJ81rioJB7KqA 746RSWfeBHXfIner3vSyjE6bo24V85TlkvU7BWiQxsfpAEk4hPgVxM09Wj9tazGDQs3J 3PNDt0Nm84rXPdV/qYxqY0MonNsMdFbOpLB9yTjYMb0y1BMXPXPiYKZ7F6U0nLYfhIsk 0QZhUBIlcL6yjLzpK/bkRv7wgbn6egUERKZeT8vFyWX1W1p2yHCXQ4fQ0hZVtSrTYxgI Njmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=8oEU82ZVitBz4Ig2Bwfp5Is7/SICE7dzdyHbdHkAUH0=; b=SdYKoPbJ1AmPW1y+VKzEIS5OIk3cFhlhgh+5ihgo0Cgdky90pTWljJqju02SnH/a7r Wg2E3ALs1pbWPym4THnnzVj51UjNH02rf5EpZVe2QdrLvHwFz8Em0T1eYo2OQspXPDdT CcfLxRQeAjNw4DqS0ZB9ktmiGP4yEqHgpwxVgIBcXV60Xp9IYWR9qNosZZXf8ybiSg61 KPnkSupgJMOoSfJVjhR0uFX1YwiX5dboerOKeoO0OjSX6i7tI7sIUhSkltLAiDLdeYHQ Guho9Lc0F8CQskuUpRbrdo1upfqSAe0wuhAjkKwcvlnA7U2Y00VM/XLsbdGS4eSRdh5i FA7w==
X-Gm-Message-State: AE9vXwO9nlUJ1KEgJ+XTpzUWmqLXxbauTtyMmWvw5CwDYRqwFiNyOdtH039i9p6T2aVaPwd4zBPfkjoCL89oJw==
X-Received: by 10.55.31.85 with SMTP id f82mr34302500qkf.213.1473178705739; Tue, 06 Sep 2016 09:18:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.20.69 with HTTP; Tue, 6 Sep 2016 09:18:25 -0700 (PDT)
From: Dan Romascanu <dromasca@gmail.com>
Date: Tue, 06 Sep 2016 19:18:25 +0300
Message-ID: <CAFgnS4XHn056VuQxZv7ovtoP6wVQphSsFP7QG_tiSsg2fjSOpQ@mail.gmail.com>
To: gen-art@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/EJIoYrh7p_K-iXXpY-RBpkZQgjY>
Cc: draft-ietf-mptcp-experience.all@tools.ietf.org
Subject: [Gen-art] Gen-ART LC review of draft-ietf-mptcp-experience-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2016 16:18:34 -0000
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mptcp-experience-06 Reviewer: Dan Romascanu Review Date: 9/6/16 IETF LC End Date: 9/13/16 IESG Telechat date: 9/15/16 Summary: Ready with issues A very useful and well written document, which gathers implementation and deployment experience and expands the list of the Multipath TCP Use Cases. A few minor issues described below, if addressed, could improve the clarity and usability of the document. Major issues: Minor issues: 1. The 'Introduction' section starts with the statement: > Multipath TCP was standardized in [RFC6824] and five independent implementations have been developed. Saying 'was standardized' seems misleading to me, as RFC 6824 is an experimental RFC, so not even standards-track (this putting aside the discussions whether RFCs are standards). Actually at no point this document mentions that Multipath TCP is Experimental, this seems odd. 2. It would be useful to clarify the statement about the iOS implementation of Multipath TCP in the Introduction by mentioning what 'single application' is referred. > However, this particular Multipath TCP implementation is currently only used to support a single application.' 3. I am questioning whether the 'Multipath TCP proxies' section really belongs to the use cases or rather to operational experience. After all it's about a strategy of deployment of Multipath TCP in cases where clients and/or servers do not support Multipath TCP but the need exists probably because of the combination of one or several other use cases. 4. In section 3.5: >There have been suggestions from Multipath TCP users to modify the implementation to allow the client to use different destination ports to reach the server. This suggestion seems mainly motivated by traffic shaping middleboxes that are used in some wireless networks. In networks where different shaping rates are associated to different destination port numbers, this could allow Multipath TCP to reach a higher performance. As of this writing, we are not aware of any implementation of this kind of tweaking. Beyond the potential problems described in the following paragraph, is such a 'tweak' consistent with the protocol definition, or would it need to cause changes in the protocol as defined now? A clear recommendation seems to be needed here. 5. A more clear recommendation would be useful also in 3.8. It is not clear here whether the segment size selection is a design or a tuning issue that can/should be added to applications. Nits/editorial comments: 1. Section 3.12 contains a timed statement 'As of September 2015 ...' which should be updated or maybe edited to make it less time-dependent. 2. It seems to me that [RFC6824] and [RFC6181] should be Normative References as they describe the protocol extensions, and the initial list of use cases which is expanded by this document. Without reading these two documents, this one does not make too much sense.
- [Gen-art] Gen-ART LC review of draft-ietf-mptcp-e… Dan Romascanu
- Re: [Gen-art] Gen-ART LC review of draft-ietf-mpt… Jari Arkko