Re: [quicwg/base-drafts] PMTUD details (#614)

[martinduke <[e-mail]>]

@gloinul, Responses inline:

> @martinduke I have also re-read RFC 4821. And I first of all I think being explicit on the things you consider redundant is the better approach. This from the aspect, that if we can spend time to write a sentence or two, and save time and get more consistent behavior from implementations it is well spent time in my view.

Fair enough. Expect a revised PR #849 shortly.
> 
> Additional issues worth discussing in the text are:
> 
> ICMP verification for any received Message to too Big (Not only relevant for PMTUD). This is likely rather straightforward, but do require the QUIC implementation to be able to match the truncated part of the encrypted QUIC packet against itself. This likely implies storing X number of bytes of the encrypted packet for this verification. Or will we actually use any encryption that will be able to perform partial decryption and use that to verify that these initial bytes matches valid QUIC headers?

I believe these considerations have long been addressed in "Special considerations for PMTU Discovery".

> Issues with setting DF bit from user land (as SHOULD requirement) in 4821. It is somewhat discussed in RFC4821, but clearly an issue for many QUIC implementations. What advancements since 4821 is it worth bringing up here?

I acknowledge that user-land QUIC implementations may have issues, but I am utterly at a loss as to what to say about it. Can you suggest some text?

> 
> Storage and reuse of PMTUD information in stack instance releated to differnet paths. Applies for multi-path as well as implementations opening a number of connections. At a minimum a clear definition of what QUIC semantics corresponds to a path, and thus can have different MTU values.

In the existing text, it says: 
"QUIC endpoints that implement any kind of PMTU discovery SHOULD maintain an
estimate for each combination of local and remote IP addresses (as each pairing
could have a different maximum MTU in the path)."
Is that insufficient, in your view?
 
> For user-land QUIC implementation it can actually be a bit of a challenge to correctly know how much headers would be added. A challenging example would be QUIC over ICE in a WebRTC context. Where it is actually the ICE stack that controlls which path and what headers and NAT/FW traversal mechanism are in place, such as TURN that changes the header overhead between candidate pairs. This is in relation to RFC 4821 Section 5.1.

Again, I recognize the problem but am at a loss for what to write. Can you suggest text?

-- 
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/issues/614#issuecomment-343000854