RE: [tsvwg] WGLC for DPLPMTUD

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed this document to get a head start on the AD review. There are a few issues that needs to be addressed. When these have been addressed it is from my perspective ready for publication. 

Several issues have to do with the relation to QUIC and it specification. Therefore I do CC the QUIC WG to see if we can agree how to handle where to describe the QUIC protocol's implementation of DPLPMTUD. See issue 5 and forward. 

Reviewed HTML version as this is an v3 document and like to see how the SVG etc looks. https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-12.html
	
1. Should this document beyond updating 4821, actually update RFC8085 also? That would require a small section basically saying that for applications that consider using RFC 4821 style should directly look into this document. Given the UDP context of RFC 8085 directly reading this document is much more useful. 	

2. Section 1.3: 
	
Section 6 specifies the method for a set of transports, and provides information to enable the implementation of PLPMTUD with other datagram transports and applications that use datagram transports.
	
Shouldn't the transports this document actually defines be explicitly listed here? 
	
3. Section 3. Bullet 4: 
Processing PTB messages
	
A PTB message MUST NOT be used to increase the PLPMTU [RFC8201].
	
I assume the requirement here is to not directly raise PLPMTU to the given PTB_SIZE. However, using it to indicate that probing may be worth performing around the given PTB_SIZE can be done? The issue from my perspective with the sentence is that "used" may include so many actions, not only the direct update of the PLPMTU estimate with PTB_SIZE.
	
4. Section 4.3:
	
This can be triggered when a validated PTB message is received, or by another event that indicates the network path no longer sustains the current packet size, such as a loss report from the PL, or repeated lack of response to probe packets sent to confirm the PLPMTU. 
	
Would not "loss reports from the PL" be better than "a loss report from the PL"? It is not like the Black hole detection will trigger on a single loss or? 
	
	
5. Section 6.3:
Inconsistency between 6.3 and draft-ietf-quic-transport24. 
	
It recommends the use of PADDING frames to build the probe packet. Pure probe-only packets are constructed with PADDING frames and PING frames to create a padding only packet that will elicit an acknowledgement.
	
This is now stated in 14.3. I also note that draft-quic-transport wrongly references 6.4 when it is 6.3. 
	
As this is a question of coordination between these two specifications, I do wonder if it would not be best to move the whole 6.3 into draft-ietf-quic-transport section 14.3 so that the QUIC adaptation is contained in the QUIC specification. It will requires some changes to this text to correctly point in to the DPLPMTUD specification but likely minimizes these inconsistencies. Clearly this needs to be handshaken with the QUIC WG. 
	
6. Section 6.3.2:
	
The current specification of QUIC sets the following: 
 ○ BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to 1200 bytes to confirm the path can support packets of a useful size.
 ○ MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has fallen below 1200 bytes MUST immediately stop sending on the affected path.
	
Draft-ietf-quic-transport-24 states: 
	
  When implementing the algorithm in Section 5.3 of [DPLPMTUD], the
  initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC
  packet size (1232 bytes for IPv6 and 1252 bytes for IPv4).
	
7. Section 6.3.4: 
QUIC operates over the UDP transport, and the guidelines on ICMP validation as specified in Section 5.2 of [RFC8085] therefore apply. In addition to UDP Port validation QUIC can validate an ICMP message by looking for valid Connection IDs in the quoted packet.
	
Section 14.2 of draft-ietf-quic-transport-24 includes much more on ICMP validation. Also the issue discussed in 14.3.1 is relevant here. 

Cheers

Magnus Westerlund