RE: Treatment of ICMP for PMTU

["Lubashev, Igor" <[e-mail]>]

  *   Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my perspective, the important is that one uses this a signal for checking the PMTU.

From my perspective, there are two things that are important here:

  1.  Use PTB signal to start probing (as you said).  This is section 3.3.
  2.  Identify cases, when you can set PMTU to PTB_SIZE immediately upon receipt of PTB, while the probing is happening.

Plus one more thing that is not in that draft at all – I think it is prudent to respect PTB, even if that PTB is not validated (i.e. w/o on-path proof, using my lingo), if PTB_SIZE is large enough (to be defined how large).  It probably deserves its own thread in tsvwg.


  *   Igor


From: Magnus Westerlund [mailto:[e-mail]]
Sent: Monday, July 02, 2018 4:46 AM
To: Lubashev, Igor <[e-mail]>; Eggert, Lars <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>; Martin Duke <[e-mail]>
Subject: Re: Treatment of ICMP for PMTU


Hi,

Den 2018-06-29 kl. 02:30, skrev Lubashev, Igor:



 • What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)?



Isn't this sufficiently covered in 4821?



Not really.  Or, at least I could not find anything more useful there then: "If an ICMP PTB message is received matching the probe packet, then search_high and eff_pmtu MAY be set from the MTU value indicated in the message."  So 4821 seems silent on what to do if ICMP is received for a non-probe packet, and it seems silent on how one could decide whether to set search_high and eff_pmtu from the MTU in ICMP or not (saying "MAY" does not really help here).  These questions are what I am trying to address for QUIC.



4821 uses MAY in the sentence above, since it does not really give any better indication.  This PR draws a distinction between ICMP w/ and w/o on-path proof and in some specific cases, it recommends a SHOULD.




If you look at the updated PLPMTUD:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Ddatagram-2Dplpmtud_&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=uDGI9jiS7Geg3dbv7-6X13iWfUICKy3fOiekJYaO_HA&s=MQRhWnsLTgO3sRXM-EnMvYTRoX9HubTysSfT_FPicJk&e=>

3.3.  Reducing the PLPMTU: Confirming Path Characteristics



   If the DPLPMTUD method detects that a packet with the PLPMTU size is

   no supported by the network path, then the DLPMTUD method needs to

   validate the PLPMTU. This can happen when a validated PTB message is

   received, or another event that indicates the network path no longer

   sustains this packet size, such as a loss report from the PL



   All implementations of DPLPMTUD are REQUIRED to provide support that

   reduces the PLPMTU when the actual PMTU supported by a network path

   is less than the PLPMTU.

Section 4.9 says:

   PROBE_DONE: The PROBE_DONE state indicates a successful end to a

      probing phase.  DPLPMTUD remains in this state until either the

      PMTU_RAISE_TIMER expires or a received PTB message is verified.

However, I have to say that the draft is a bit unclear on what to do at this point.

I guess the options are two.

Probe starting at PTB_SIZE or verify Base_MTU and then probe up. From my perspective, the important is that one uses this a signal for checking the PMTU.

I will start a thread on TSVWG WG mailing list regarding the lack of specific text in their draft for this case.

Cheers




Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  [phone]

Torshamnsgatan 23           | Mobile [phone]

SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>

----------------------------------------------------------------------