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

From: martinduke <[email-masked]>
Date: Wed, 08 Nov 2017 23:52:11 +0000 (UTC)

@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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Nov 2017 00:02:26 +0000 (UTC)

The net effect of running on top of ICE, without access to the path selection that ICE is performing, is likely that you end up with the lowest common path MTU over time.  It's the same thing as what you get when there is a router that picks different paths through the network without you being aware of it.  The MTU you see isn't constant over time, so you likely end up with the lowest value (assuming that you don't ever fixate on a particular value after having observed that value working).

-- 
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-343002821

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Nov 2017 02:52:03 +0000 (UTC)

I will try to write some text around the user land setting of DF bit. It will probably take 2 weeks. 

When it comes to ICE, I think @martinthomson is correct what would happen in a naive implementation.  What I would add beyond a general suggestion is that an ICE implementation should actually notify the higher layers upon known path changes so QUIC can actually perform the right path changes functions.

-- 
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-345130435