Re: Treatment of ICMP for PMTU

["Gorry (erg)" <[e-mail]>]

See below : 

> On 2 Jul 2018, at 19:19, Lubashev, Igor <ilubashe=[e-mail]> wrote:
> 
> 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. 

Fine (for me) to say to use as PROBED_SIZE, to trigger an immediate check that this size works. 

> 
> From my perspective, there are two things that are important here:
> Use PTB signal to start probing (as you said).  This is section 3.3.
> 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.

That last part, I  less clear about - and I think we see there are cases where that may not do what would be best. Please  do feel discuss in tsvwg...

Gorry 
>  
> 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/
> 
> 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]
> ----------------------------------------------------------------------