Re: [tsvwg] Martin Duke's Yes on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)

Martin Duke <martin.h.duke@gmail.com> Fri, 03 April 2020 15:42 UTC

Return-Path: <martin.h.duke@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 7CEB23A1939; Fri, 3 Apr 2020 08:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1OkN8qDLfeiO; Fri, 3 Apr 2020 08:42:38 -0700 (PDT)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 45AD93A18DD; Fri, 3 Apr 2020 08:42:36 -0700 (PDT)
Received: by mail-il1-x135.google.com with SMTP id 7so7683041ill.2; Fri, 03 Apr 2020 08:42:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S4kxgAltOl3WZrsyeBgqbCyug+yIaeLiEWDVd7wPByE=; b=agXMMUHqGhnFD1g7ZReV+C2ddLEX/217TD2JhijSg/j9+Wfp54Ifa6OxoBXGfx04xw Q/y9xs/IwdIVuHaBmM0KfhmGBs4MV0YKWPy57CeRJ6o8vUI577QRelR0y0cEfEA43Paa 3HcuTow+1Q6Ggg6CdT9wcILhvsOz/prl419RgT41llr6PEMjna4pD4twoCCyDBF2tIdx hlzV0MMBPnunxunVWgVG+HVXz09/daEnSQPoM6lEgWFDLkEw2Fr5x+bu8Mv9TCp6kHZB 6xB7gQQPr2+Wfi4VdhuAi5AdJ0Is5ovdAbV/HAoqvdXy/H9bPXmAyVyuTYebKAMD63sS hXFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S4kxgAltOl3WZrsyeBgqbCyug+yIaeLiEWDVd7wPByE=; b=C95mLc7nEmG0XWaroXGql+yAuvIyl+x1MNDi/EXZHj/iEIdJ7tqMUxYWwI4kCk23PG 8uDfjyDMtP5+Uf2YxGJIhHStpXPmZZv5cFfGxXGjYf2gj5TN5qOAkw5L0w1ZCWs1TtPH 7uCnF/vBXKCNxRFSN/85/1r4ZRas9uWEdK34cmXqVpdgEXqY0OTLaA9fYeMBifyeCR05 Tdz3p0nebH5zt0GEk/Pqu6JKDk5ScUNwlJlncCkb7dpAzYW38AFFjgemwCJrwj6p6yqx aACvHavqnJuOPdk63aV7JmoobkqywJJtHMI1rIhytjUyziKkbqVQVwZT6BB61zpukCA/ gnPA==
X-Gm-Message-State: AGi0PuZguhiKVaDm/d8C9Lo8YwWQEAkaoSjVz6p5++Hf6+kzWw0URZ8b Lw9Cf6RMlSNlflxuuFRyGvok93UK/hiNqfywVY/CHOd4
X-Google-Smtp-Source: APiQypIzo04BRr+a6ppoolbKqF/D2pST+DJcqZM3wTqHUCSrPsxZqH4bLqX9zB7jbgsCmpkSeX5bZ0cO0UfyBaCgAso=
X-Received: by 2002:a92:8410:: with SMTP id l16mr9349942ild.288.1585928555418; Fri, 03 Apr 2020 08:42:35 -0700 (PDT)
MIME-Version: 1.0
References: <158561977952.11604.17536804469227337572@ietfa.amsl.com> <56d5a368-8f43-980a-a54f-bc6dc3dfd937@erg.abdn.ac.uk>
In-Reply-To: <56d5a368-8f43-980a-a54f-bc6dc3dfd937@erg.abdn.ac.uk>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 3 Apr 2020 08:42:25 -0700
Message-ID: <CAM4esxTuTT7TDmieu527edyZE8VZimmrnM5MdTQM+XJs0q3+TQ@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tsvwg-datagram-plpmtud@ietf.org, tsvwg-chairs@ietf.org, tsvwg <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002f59f605a264c4ab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/p1ZLZeS2NlAwrtaf6ymA_jAsTb4>
Subject: Re: [tsvwg] Martin Duke's Yes on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 03 Apr 2020 15:42:40 -0000

Gorry, the suggested change is satisfactory.

Thanks.

On Wed, Apr 1, 2020 at 12:54 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
wrote:

> Martin Duke has entered the following ballot position for
> draft-ietf-tsvwg-datagram-plpmtud-17: Yes
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm excited for this to go to RFC once the QUIC reference clears.
>
> Normative issue:
>
> Sec 3, item #9 "An update to the PLPMTU (or MPS) MUST NOT modify the
> congestion
> window". Would it not be OK to round down the congestion window to remain a
> multiple of the MPS? Probably not a big issue in practice, but I would
> hate to constrain an implementer in this way. I would suggest "MUST NOT
> increase".
>
>  >> GF:
> If a protocol wants to change the way it uses the Cwnd, because the MPS
> had changed, then it needs to take care of that when it works out
> whether Cwnd is limiting the sender. The packets can be any size up to
> the MPS.
>
> A protocol using only one size of packet would need to change the Cwnd
> limit (the number of outstanding packets) based on the Cwnd when it
> decided to use a new size, not when it was told a larger size was
> possible. That’s up to the protocol... care is needed here, because the
> DPLPMTU can be updated many times in a search. Usually it will grow
> depending on the search pattern used for probes. These changes do not
> themselves reflect any change in congestion - a sender that adjusts the
> cwnd depending on the current PMTU size, can get rounding errors as the
> PLPMTU increases/decreases.
>
>  >> GF: So the ID could say something about when the PL protocol
> operates in terms of packets, rather than bytes. That may be the root of
> the question you ask? I suggest new text to be added:
>
> OLD:
>          An update to the PLPMTU (or MPS) MUST NOT increase the congestion
>           window measured in bytes [RFC4821].  Therefore, an increase in
>           the packet size does not cause an increase in the data rate in
>           bytes per second.
>
> NEW:
>          An update to the PLPMTU (or MPS) MUST NOT increase the congestion
>           window measured in bytes [RFC4821].  Therefore, an increase in
>           the packet size does not cause an increase in the data rate in
>           bytes per second.
>
>           A PL that maintains the congestion window in terms of a
>           limit to the number of outstanding fixed size packets SHOULD
> adapt
>           this limit to compensate for the size of the actual packets
>           that it sends. [RFC7141] provides guidance on appropriate
> transport
>           congestion  reactions when a PL uses a certain packet size.
>
> Does this seem helpful?
>
> Gorry
>
> —
>
> Nits:
>
> Sec 2. In the definition for EMTU_R, put "the largest datagram size that
> can be
> reassembled" in quotes, and delete "by EMTU_R (Effective MTU to receive)"
>
> Sec 4.1. delete word in brackets:  "A PL that uses a probe packet
> carrying [an]
> application data..."
>
> Sec 4.6.2 I think this list of inequalities would be easier to read if
> it was
> ranked in order of increasing PL_PTB_SIZE.
>
> 5.1.1. s/up to data/up to date
>
>  >> GF these issues will all be resolved in the next version.
>