From: Xin Long > Sent: 22 June 2021 19:05 > > Overview(From RFC8899): > > In contrast to PMTUD, Packetization Layer Path MTU Discovery > (PLPMTUD) [RFC4821] introduces a method that does not rely upon > reception and validation of PTB messages. It is therefore more > robust than Classical PMTUD. This has become the recommended > approach for implementing discovery of the PMTU [BCP145]. > > It uses a general strategy in which the PL sends probe packets to > search for the largest size of unfragmented datagram that can be sent > over a network path. Probe packets are sent to explore using a > larger packet size. If a probe packet is successfully delivered (as > determined by the PL), then the PLPMTU is raised to the size of the > successful probe. If a black hole is detected (e.g., where packets > of size PLPMTU are consistently not received), the method reduces the > PLPMTU. This seems to take a long time (probably well over a minute) to determine the mtu. What is used for the actual mtu while this is in progress? Does packet loss and packet retransmission cause the mtu to be reduced as well? I can imagine that there is an expectation (from the application) that the mtu is that of an ethernet link - perhaps less a PPPoE header. Starting with an mtu of 1200 will break this assumption and may have odd side effects. For TCP/UDP the ICMP segmentation required error is immediate and gets used for the retransmissions. This code seems to be looking at separate timeouts - so a lot of packets could get discarded and application timers expire before if determines the correct mtu. Maybe I missed something about this only being done on inactive paths? David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
