Re: [quicwg/base-drafts] Integrate QUIC text from DPLPMTUD (#3693)

[Gorry Fairhurst <[e-mail]>]

See later.

On 26/05/2020 10:14, Magnus Westerlund wrote:
>
> *@gloinul* commented on this pull request.
>
> Some feedback on the text.
>
> ------------------------------------------------------------------------
>
> In draft-ietf-quic-transport.md 
> <https://github.com/quicwg/base-drafts/pull/3693#discussion_r430246749>:
>
> > @@ -3797,17 +3797,23 @@ later time in the connection.
>   The QUIC packet size includes the QUIC header and protected payload, but not the
>   UDP or IP header.
>   
> +QUIC depends upon a minimum packet size of at least 1280 bytes.
> +This is the IPv6 minimum size
> +{{?RFC8200}} and is also supported by most modern IPv4 networks.
> +Assuming the minimum IP header size, this results in a
> +QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4.
>
> Should there be an addition to the "QUIC maximum packet size" like 
> initial or base line to indicate that the QUIC maximum packet size is 
> actually a variable that can be changed by the PMTUD/DPLPMTUD?
>
> ------------------------------------------------------------------------
>
> In draft-ietf-quic-transport.md 
> <https://github.com/quicwg/base-drafts/pull/3693#discussion_r430255170>:
>
> >  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets
> -larger than 1280 bytes. Assuming the minimum IP header size, this results in a
> -QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. A QUIC
> -implementation MAY be more conservative in computing the QUIC maximum packet
> -size to allow for unknown tunnel overheads or IP header options/extensions.
> +larger than the minimum QUIC packet size.
> +
> +All QUIC
> +packets other than PMTUD/DPLPMTUD probe packets SHOULD be sized to fit within the
> +maximum packet size to avoid the packet being fragmented or dropped
> +{{?RFC8085}}.
> +
> +If a QUIC endpoint determines that the PMTU between any pair of local and remote
> +IP addresses has fallen below the smallest allowed maximum packet size, it MUST immediately
>
> Isn't the "smallest allowed maximum packt size" equal to the "minimum 
> QUIC packet size"? I guess strictly not, as smallest allowed maximum 
> packet size is on IP level which is 1280. While "minimum QUIC packet 
> size" based on the initial requirement is 1200 bytes and results in a 
> IP level value that is slightly less than 1280. I think this needs 
> some alignment. Maybe basing it on the 1200 bytes minimum QUIC packet 
> size and say that smallest supported Maximum Packet Size is then 1200 
> plus overhead for IP/UDP.
>
> ------------------------------------------------------------------------
>
> In draft-ietf-quic-transport.md 
> <https://github.com/quicwg/base-drafts/pull/3693#discussion_r430269451>:
>
> > +state when the QUIC connection handshake has been completed and
> +the endpoint has established a 1-RTT key.
>
> So, this was an attempt from me to correct something that looked even 
> more broken in the earlier text in the TSVWG document. If handshake is 
> complete is a good term lets use it.
>
> So I think it is relevant to at least go through the implication of 
> sending DPLPMTUD probes prior to handshake complete. So one possible 
> implementation here could be to first send your initial packet with 
> 1280 as MPS. Then you use the rest of your IW=10 to send a broad side 
> of Path MTU probes of various sizes checking a number of common sizes 
> up to the client's local interface's MPS. So in relation to recovery 
> that defines the initial window to 10/max_datagram_size with a limit 
> of max (14720, 2/max_datagram_size). I make an assumption that one 
> will in this case start with max_datagram_size=1200. Thus one can fit 
> some number of probes. So allow DPLPMTUD to use 0-RTT keys to send 
> probes I think is likely to result that the client to server handshake 
> flight will often contain 10-12k of data even if there are no 0-RTT 
> application data. That might be a good investment, but are we certain 
> of the DoS properties of this?
>
> So my though was simply to be a bit conservative here and ensure that 
> both endpoints know there are someone there that will report delivery 
> of the probes before sending them. But, this is clearly something the 
> QUIC WG can discuss and change.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> <https://github.com/quicwg/base-drafts/pull/3693#pullrequestreview-418084163>, 
> or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLESDHHRZ3EADW6P2ODLRTOB7JANCNFSM4NJQ432A>.
>
The reason why we didn't suggest this within DPLPMTUD, was two things:

* Using the limited for IW for packet probes rapidly consumes the 
current IW space in bytes, and we were unconvinced of the importance to 
tenatively try a large PMTU during the first RTT.

* I was not aware of measurement data about how changing the initial 
flight of data would impact congestion collapse, since at this point 
there is no feedback from the receiver, and it seems, at least to me, to 
raise questions regarding stability with large numbers of flows and also 
as you note, the potential DoS opportunities.

So, I'd be interested in what people think about this, and see any 
analysis and experience.

Gorry



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3693#issuecomment-633921344