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

[Gorry Fairhurst <[e-mail]>]

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.