Re: Update to draft QUIC DPLPMTUD text i draft-ietf-tsvwg-datagram-plpmtud

[Christian Huitema <[e-mail]>]

On 5/26/2020 5:32 AM, Timo Völker wrote:
> thanks for sharing your experiences. Especially for the in-equation.
>
> I wonder how to determine the values.
>
> anticipated_gain
> It is easy if we know how much data we are going to send over a connection, but how can QUIC figures that out in advance?

This tends to depend on the application running on top of QUIC. In the
case of HTTP3, the server knows which documents have been requested by
the client, and the size of these documents. That gives an indication of
the "committed load". For other applications, the server has to make an
educated guess based on application profile, statistics, etc. In my
implementation of DNS over QUIC, for example, I just turn off PMTUD
because it is seldom useful for the DNS application.

> Also, a discovered PMTU could be reused in the next connection to the same destination. How to anticipate whether and how often we will reconnect in a short term?
That's another can of worms. I suppose this could be incorporated in the
general framework. It is not clear that two connections to the same
destination will encounter the same PMTU -- routing could have changed.
I guess that recent tests on the same source-destination path will
inform the "probability of success" of trying a specific MTU, but that
if tests are old it is better to assume some regression to average. On
the benefit side, measured frequency of past connections to the
destination could inform the potential benefits.
>
> probability_of_success
> I think, measurements can tell (or have told?) us.

Yes. Big services with millions of users can get lots of measurements,
and so have an advantage there. It would be very nice if there were some
publicly available measurements, for the benefit of smaller deployments.

>
> cost-of_probe
> What do you mean with cost? The extra load for the network or the consequences for the endpoints?
> It seems to me, the costs for a sender is quite high in QUIC. If we follow the spec, a sent probe packet consumes cwnd and, if it gets lost (for whatever reason), it reduces the (New Reno) cwnd, right? Did you include exceptions for probe packets?

In my implementation, I just use the number of octets to be sent, and I
do have an exception for probe packets. Other implementations might have
a different interpretation of what the cost is.

-- Christian Huitema