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

[Martin Duke <[e-mail]>]

Gorry, the suggested change is satisfactory.

Thanks.

On Wed, Apr 1, 2020 at 12:54 AM Gorry Fairhurst <[e-mail]>
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.
>