Re: Update to draft QUIC DPLPMTUD text i draft-ietf-tsvwg-datagram-plpmtud

[Magnus Westerlund <[e-mail]>]

Hi,

So what Gorry says appear correct. And it is a constant but its value could in
worst case be not only interface but actually path dependent. The reason being
that if the lower layers adds headers in specific cases. 

Although use of IPv6 extension headers are not problem free there might be cases
where such a header is added for some paths but not others. Thus, specifying the
MIN_PLPMTU correctly to be stable acrosss interfaces and paths could be
problematic. But for QUIC as Gorry says the stake is already in the ground and
it is in fact reasonable maybe to be more precise to say that a default
MIN_PLPMTU to use can be 1200 bytes as we don't expect QUIC to work over paths
that don't support this. 

We might get some interesting questions on the padded handshake packets when
some want to run QUIC as IOT transport over radios such as what LPWAN WG
discusses where it is very costly to send 1200 bytes packets. The radio blocks
are more in the range of 32-64 bytes if I remember correctly. 

So I think this discussion is pointing to that we should actually move Section
6.3 from draft-ietf-tsvwg-datagram-plpmtud into draft-ietf-quic-transport so
that the details can still be polished. 

Cheers

Magnus Westerlund

On Thu, 2020-05-14 at 20:19 +0100, Gorry Fairhurst wrote:
> To me, this is a PL choice, and likley a constant for a PL.
> 
> The PL simply configures as an endpoint what size it needs. If you need 
> to work smaller than that size, then the PL has to utilise IP 
> fragmentation, etc. The DPLPMTUD alg won't probe for smaller sizes.
> 
> I expect most apps will actually use a MIN value that is irrespective of 
> IP version, such as 1200B, but the app could choose a smaller number - 
> which is permitted for IPv4, but in reality 1200B is likely good. For 
> QUIC, I'd expect ~1200B and no IP Frag - but that's QUIC's decision. 
> BASE_PLPMTU and MIN_PLPMTU can be set the same.
> 
> Gorry
> 
> On 14/05/2020 19:50, Michael Tuexen wrote:
> > 
> > > On 14. May 2020, at 19:20, Martin Duke <[e-mail]> wrote:
> > > 
> > > I don’t understand the MIN_PLPMTU language in 6.3.2. This is a constant
> > > set based on the IP version. I don’t understand how it can change on a
> > > path?
> > 
> > I guess it should state that if the PLPMTU falls below MIN_PLPMTU, you stop
> > sending packets.
> > 
> > Best regards
> > Michael
> > > On Tue, May 12, 2020 at 1:49 AM Magnus Westerlund <
> > > [e-mail]> wrote:
> > > QUIC WG,
> > > 
> > >   
> > > 
> > > In response to the IESG evaluation of 
> > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ some
> > > changes was made to the QUIC chapter.
> > > 
> > >   
> > > 
> > > The current text is included below. And a Diff for the changes in this
> > > section -19 to -21 is here:
> > > 
> > >   
> > > 
> > > QUIC related section is 6.3:
> > > 
> > > 
https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-datagram-plpmtud-19&url2=draft-ietf-tsvwg-datagram-plpmtud-21
> > > 
> > >   
> > > 
> > > My plan is to approve this document on Friday after 12:00 (CEST) if not
> > > anyone yells.
> > > 
> > >   
> > > 
> > >   
> > > 
> > > 6.3.  DPLPMTUD for QUIC
> > > 
> > >   
> > > 
> > >     QUIC [I-D.ietf-quic-transport] is a UDP-based transport that provides
> > > 
> > >     reception feedback.  The UDP payload includes the QUIC packet header,
> > > 
> > >     protected payload, and any authentication fields.  QUIC depends on a
> > > 
> > >     PMTU of at least 1280 bytes.
> > > 
> > >   
> > > 
> > >     Section 14 of [I-D.ietf-quic-transport] describes the path
> > > 
> > >     considerations when sending QUIC packets.  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 acknowledgment.  Such padding
> > > 
> > >     only packets enable probing without affecting the transfer of other
> > > 
> > >     QUIC frames.
> > > 
> > >   
> > > 
> > >     The recommendation for QUIC endpoints implementing DPLPMTUD is that a
> > > 
> > >     MPS is maintained for each combination of local and remote IP
> > > 
> > >     addresses [I-D.ietf-quic-transport].  If a QUIC endpoint determines
> > > 
> > >     that the PMTU between any pair of local and remote IP addresses has
> > > 
> > >     fallen below the size required for an acceptable MPS, it immediately
> > > 
> > >     ceases to send QUIC packets on the affected path.  This could result
> > > 
> > >     in termination of the connection if an alternative path cannot be
> > > 
> > >     found [I-D.ietf-quic-transport].
> > > 
> > >   
> > > 
> > > 6.3.1.  Initial Connectivity
> > > 
> > >   
> > > 
> > >     The base protocol is specified in [I-D.ietf-quic-transport].  This
> > > 
> > >     provides an acknowledged PL.  A sender can therefore enter the BASE
> > > 
> > >     state as soon as connectivity has been confirmed.
> > > 
> > >   
> > > 
> > >     QUIC provides an acknowledged PL, a sender can therefore enter the
> > > 
> > >     BASE state as soon as the connection handshake has been completed and
> > > 
> > >     the endpoint has an 1-RTT key established.
> > > 
> > >   
> > > 
> > > 6.3.2.  Sending QUIC Probe Packets
> > > 
> > >   
> > > 
> > >     Probe packets consist of a QUIC Header and a payload containing a
> > > 
> > >     PING Frame and multiple PADDING Frames.  A PADDING Frame is
> > > 
> > >     represented by a single octet (0x00).  Several PADDING Frames are
> > > 
> > >     used together to control the length of the probe packet.  The PING
> > > 
> > >     Frame is used to trigger generation of an acknowledgement.
> > > 
> > >   
> > > 
> > >     The current specification of QUIC sets the following:
> > > 
> > >   
> > > 
> > >     *  BASE_PLPMTU: A QUIC sender pads initial packets to confirm the
> > > 
> > >        path can support packets of the required size, which sets the
> > > 
> > >        BASE_PLPMTU and MIN_PLPMTU.
> > > 
> > >   
> > > 
> > >     *  MIN_PLPMTU: A QUIC sender that determines the MIN_PLPMTU has
> > > 
> > >        fallen MUST immediately stop sending on the affected path.
> > > 
> > >   
> > > 
> > > 6.3.3.  Validating the Path with QUIC
> > > 
> > >   
> > > 
> > >     QUIC provides an acknowledged PL, therefore a sender does not
> > > 
> > >     implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
> > > 
> > >   
> > > 
> > > 6.3.4.  Handling of PTB Messages by QUIC
> > > 
> > >   
> > > 
> > >     QUIC validates ICMP PTB messages.  In addition to UDP Port
> > > 
> > >    validation, QUIC can validate an ICMP message by using other PL
> > > 
> > >     information (e.g., validation of connection identifiers (CIDs) in the
> > > 
> > >     quoted packet of any received ICMP message).
> > > 
> > >   
> > > 
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------