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

Martin Duke <> Fri, 03 April 2020 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CEB23A1939; Fri, 3 Apr 2020 08:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1OkN8qDLfeiO; Fri, 3 Apr 2020 08:42:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45AD93A18DD; Fri, 3 Apr 2020 08:42:36 -0700 (PDT)
Received: by with SMTP id 7so7683041ill.2; Fri, 03 Apr 2020 08:42:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <>
In-Reply-To: <>
From: Martin Duke <>
Date: Fri, 03 Apr 2020 08:42:25 -0700
Message-ID: <>
To: Gorry Fairhurst <>
Cc: The IESG <>,,, tsvwg <>
Content-Type: multipart/alternative; boundary="0000000000002f59f605a264c4ab"
Archived-At: <>
Subject: Re: [tsvwg] Martin Duke's Yes on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Apr 2020 15:42:40 -0000

Gorry, the suggested change is satisfactory.


On Wed, Apr 1, 2020 at 12:54 AM Gorry Fairhurst <>

> Martin Duke has entered the following ballot position for
> draft-ietf-tsvwg-datagram-plpmtud-17: Yes
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.