Re: [tsvwg] WGLC to publish draft-ietf-tsvwg-multipath-dccp-13 as PS will close 5th March 2024

Chris Box <chris.box.ietf@gmail.com> Tue, 05 March 2024 18:33 UTC

Return-Path: <chris.box.ietf@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64792C14F69E; Tue, 5 Mar 2024 10:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRuhg2SlMjeC; Tue, 5 Mar 2024 10:33:43 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54BBC14F5ED; Tue, 5 Mar 2024 10:33:43 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-512ed314881so5614301e87.2; Tue, 05 Mar 2024 10:33:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709663621; x=1710268421; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eebSKQgUse/VW6BntEFjGZp+VCbqX3bleIXTTYedfRE=; b=ANCGjJmhx31mf9y8utjx7ZuYfTL4YAyuvkUK/oIm7NSNcFQQ4sz7MoVYidIvg8Bd0b mxuXRo8eD7vkvwfdGb5m/p+VLwJFDrHXKAGJauAJa3Z2ZRbUdMLQr40r0tViwko+nI2D rASZ1Yc7uD6hENnpek4WDnlB6gw0S85XdZyGPQAWPMFTmTtJDlK5P9fzCTD6qrnXtzJb fTrvg8U3cRbN+nACRQeSOwYR6NHsUf7J8QaU4hKoCTapuDwBWKqoZA2Nb24KwbSAZKT8 FEYmviDp9oePL3tHiFC7FfnjID8f/kLlfsmQtZ9yKT3FydQKv1G3S/97c5fpqbgYvUQe omcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709663621; x=1710268421; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eebSKQgUse/VW6BntEFjGZp+VCbqX3bleIXTTYedfRE=; b=aOGoyCeo8/i4NX9rarUJLpgvDbXuaEBQoIpnSX3Pc9kHtgwJkbkkrVqU8r4xIvmNF1 TsfnPV23lXMEg8rHtj7trAohuVLJebzj185z+9ALIwIvhxsy1dRUz05T0PUF7kSv47uA LygCFqTYMvPLSXx/9F7f4p1wXn7EBQY1PojGbKWRar4AbGPvvtTrd+qtNNAdg0EDe4o6 wp667bZac5+XVNZmcicxuWosy/hi1eQEj15Ei5zIJXU33gmdUBWMaQwBXHsUUFpERdf7 zjmBPUpx/R6u0e+k5DWHRZ+j28QsG6Jvif6rUW/2C505etx/bk2yCmMUGmBDApW4sJ9D LEPw==
X-Gm-Message-State: AOJu0Yy3zXxICkhGIUcq4tXDtcPh7ON/Cfe0io8s23AAnvHvCgW094Bw QzV4ZRYm0QYNYgaPoxS8EtKXoLiEMq0Ci/ls3rDxX+lz8OC/2xxITBcOlqcGiCho8J/xsVOvkxn QQy/qgdmdEP6OD1BPRp3Tm4dx+vba0EYDZpk=
X-Google-Smtp-Source: AGHT+IHXTs55fjTQJOgGPLcw7Z9xsiN+H7YYrZOu/9CvMBwrYDL4MnmwEmNwoHdgyo8cM0l7ka6ml8YbLMXZsTdV2ts=
X-Received: by 2002:a05:6512:1029:b0:513:55d1:12b5 with SMTP id r9-20020a056512102900b0051355d112b5mr1595330lfr.25.1709663621203; Tue, 05 Mar 2024 10:33:41 -0800 (PST)
MIME-Version: 1.0
References: <ee2e8ebb-b6d9-4cd9-a8da-373fbc5a1300@erg.abdn.ac.uk> <da47e6aed8e24349936f9beb6912ff70@huawei.com>
In-Reply-To: <da47e6aed8e24349936f9beb6912ff70@huawei.com>
From: Chris Box <chris.box.ietf@gmail.com>
Date: Tue, 05 Mar 2024 18:33:29 +0000
Message-ID: <CACJ6M15tvmGFENj8bTeyP7TW3T7di83y-MOD0UduXa+4J-DDfw@mail.gmail.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
Cc: tsvwg-chairs <tsvwg-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d3d5b30612ee148b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/yUYWWJcTcXPvsMy1C2PahHrJALY>
Subject: Re: [tsvwg] WGLC to publish draft-ietf-tsvwg-multipath-dccp-13 as PS will close 5th March 2024
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2024 18:33:44 -0000

Hi everyone

I've read through the draft. It's good work, and the result of a lot of
effort.

I found no substantive issues to discuss, but I did have some thoughts of
an editorial nature. Please find them below. Once these have been
considered (even if they're all rejected!), I would say it's ready to
proceed to the next step.

Thanks,
Chris


1.0 Introduction

Personally I would say the text "When the datagram option is used, MP-QUIC
provides a congestion-controlled unreliable unordered datagram service,
similar to MP-DCCP" is unnecessary. Yes, MP-QUIC is an alternative to this
protocol. But I suspect what readers would find more helpful is a little
more description of the differences between the two. For example, MP-DCCP
is simpler to implement and more efficient for already-encrypted traffic.

One thing it does say is that "MP-DCCP defines procedures that facilitate
subsequent reordering." Why should the reader care about this? I can
imagine a shrug of shoulders. But if you add that reordering has been
observed to result in improved end-user throughput, then they will probably
take notice.

3 Requirements Language

It feels odd this being a top-level section. Normally it's a subsection of
the introduction.

4 MP-DCCP Protocol

Why mention "NN indicates this is non-negotiable" if we are not specifying
NN?

4.1

Typo "ore".

It states that the Version MUST be 0, which appears to conflict with the
following text about negotiating version 1 or 2. If this isn't a conflict,
adding some additional text explaining why would help.

4.2.5

In the first sentence I suggest adding "48 bit", i.e. "The MP_SEQ suboption
is used for end-to-end 48 bit datagram sequence numbers of an MP-DCCP
connection".

4.2.10

This section doesn't explain the relative meaning of different levels from
3 to 15. An example is that if I have a pair of paths with priorities 3,4
will this be used in the same way as a pair with priorities 3,15? It's
probably best for this section to point to section 4.11.

4.7

It would be good to caption the figure to indicate it shows the "most
common state transitions".