Subject: Re: [tsvwg] Comments on QUIC & draft-ietf-tsvwg-datagram-plpmtud-05

From: Tom Jones <[email-masked]>
Date: Thu, 1 Nov 2018 09:35:44 +0000

Hi Christian,

Thanks for the comments, inline

> 
> QUIC handshake allows each endpoint to advertise its "max_packet_size".
> This values should be used as the "destination PMTU" when computing the
> MAX PMTU. It might be useful to say so in section 6.4.

Okay, we will add this

> QUIC can use multiple paths. The PMTU discovery should be performed per
> path. This will inform the transport/PMTU API design.

We cover this at the start of section 5.3
	5.3.  State Machine

   	A state machine for DPLPMTUD is depicted in Figure 4.  If multihoming
   	is supported, a state machine is needed for each active path.

> In section 6.4.1. Sending QUIC Probe Packets you write "A probe packet
> consists of a QUIC Header and a payload containing only PADDING Frames."
> That should be "A probe packet consists of a QUIC Header and a payload
> containing only PING and PADDING Frames." Padding frames do not elicit
> acknowledgements, PING frames do, you want at least one PING frame in
> the probe. The transport will signal to the PMTU discovery logic that a
> probe of length L was acknowledged; it will also signal when a probe is
> considered lost.

yes, we will fix

> The QUIC specification requires that the initial packet must be at least
> 1200 bytes, and recommends to not send initial packets larger than 1280
> bytes. Initial packets are frequently a bit more than 1200 bytes. The
> transport logic can inform the PMTU discovery that an initial packet of
> length X was acknowledged, with X > 1200 bytes. In general, the
> transport can inform the PMTU discovery logic when a packet of length X
> (including probes) was acknowledged or lost.

This text in section 5.2.1 was an attempt to address transports like
QUIC that can verify connectivity on a path and the PMTU at the same
time: 

	   A PL that does not wish to support a network path with a
	   PLPMTU less than BASE_PMTU can simplify the phase into a
	   single step by performing connectivity checks with probes of
	   the BASE_PMTU size.

- [tj]

---

From: G Fairhurst <[email-masked]>
Date: Thu, 01 Nov 2018 10:02:16 +0000

>> path. This will inform the transport/PMTU API design.
Indeed, since Christian mentions this: I think it could be worth 
bubbling-up this topic.

I suggest the advent of intentional usage by transports of multi-path  
and at the same time methods in the network such as ECMP, mean that 
endpoints really need to track PMTU for EACH flow, aka by each instance 
of a packetization layer - the old idea of caching a PMTU for use by the 
next flow with the same destination address have probably now passed. 
Something we can discuss, and perhaps seek thoughts in the TSVWG session 
this coming IETF?
>> length X was acknowledged, with X>  1200 bytes. In general, the

Gorry