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

From: martinduke <[email-masked]>
Date: Tue, 10 Oct 2017 04:41:18 +0000 (UTC)

Hi Magnus,

I agree that some language about probe packets would be useful and there will be a PR shortly. This will also incorporate some advice about loss response. I would very much like @ianswett to consolidate the various actions to take upon loss detection in that document, but that's another issue.

As for "challenges with ICMP feedback", the section "Special Considerations for PMTU Discovery" is specifically meant to address this. What is that missing?

Is there anything else you'd like to see here?

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

---

From: martinduke <[email-masked]>
Date: Tue, 10 Oct 2017 12:05:20 -0700

I had another look at my RFC4821 notes. Here are some observations:
- In my opinion, someone familiar with other aspects of QUIC can read RFC 4821 and implement PLPMTUD with no more difficulty than they would with TCP or SCTP. So strictly speaking, no additional text in the QUIC spec is necessary.
- Section 6 discusses necessary protocol properties, and QUIC has them. Section 6 specifically mentions padding as a nice-to-have. PR #849, in its current state, makes this explicit.
- It would be possible to state explictly that search_low (7.2) should be the IPv6 minimum packet size, as that is the minimum size in QUIC. However, I personally find this redundant.
- It is possible to recommend an aggressive probe sizing strategy (7.3) since QUIC probe retransmissions are unnecessary. Again, I find this redundant.

I believe the current PR adequately cues the reader on relevant considerations without laboriously repeating RFC 4821. I am also persuadable that the original text is fine and the PR is unnecessary. However, I am interested if others find the current language, in conjunction with 4821, to be insufficient, and if so what pieces are ambiguous.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Oct 2017 05:17:11 -0700

@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. 

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

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

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