Skip to main content

3. Features Required to Provide Datagram PLPMTUD

The principles expressed in [RFC4821] apply to the use of the technique with any PL. TCP PLPMTUD has been defined using standard TCP protocol mechanisms. Unlike TCP, a datagram PL requires additional mechanisms and considerations to implement PLPMTUD.

Requirements for Datagram PLPMTUD​

1. Managing the PLPMTU​

For datagram PLs, the PLPMTU is managed by DPLPMTUD. A PL MUST NOT send a datagram (other than a probe packet) with a size at the PL that is larger than the current PLPMTU.

2. Probe Packets​

The network interface below the PL is REQUIRED to provide a way to transmit a probe packet that is larger than the PLPMTU.

  • IPv4: A probe packet MUST be sent with the Don't Fragment (DF) bit set in the IP header and without network layer endpoint fragmentation.
  • IPv6: A probe packet is always sent without source fragmentation (as specified in [RFC8201] Section 5.4).

3. Reception Feedback​

The destination PL endpoint is REQUIRED to provide a feedback method that indicates to the DPLPMTUD sender when a probe packet has been received by the destination PL endpoint. Section 6 provides examples of how a PL can provide this acknowledgment of received probe packets.

4. Probe Loss Recovery​

It is RECOMMENDED to use probe packets that do not carry any user data that would require retransmission if lost. Most datagram transports permit this.

If a probe packet contains user data requiring retransmission in case of loss:

  • The PL (or layers above) is REQUIRED to arrange any retransmission and/or repair of any resulting loss.
  • The PL is REQUIRED to be robust in the case where probe packets are lost due to other reasons (including link transmission error, congestion).

5. PMTU Parameters​

  • A DPLPMTUD sender is RECOMMENDED to utilize information about the maximum size of packet that can be transmitted by the sender on the local link (e.g., the local link MTU).
  • A PL sender MAY utilize similar information about the maximum size of network-layer packet that a receiver can accept when this is supplied (note this could be less than EMTU_R).

This avoids implementations trying to send probe packets that cannot be transferred by the local link. Too high of a value could reduce the efficiency of the search algorithm. Some applications also have a maximum transport protocol data unit (PDU) size, in which case there is no benefit from probing for a size larger than this (unless a transport allows multiplexing multiple applications' PDUs into the same datagram).

6. Processing PTB Messages​

  • A DPLPMTUD sender MAY optionally utilize PTB messages received from the network layer to help identify when a network path does not support the current size of probe packet.
  • Any received PTB message MUST be validated before it is used to update the PLPMTU discovery information [RFC8201].

This validation confirms that the PTB message was sent in response to a packet originated by the endpoint PL performing DPLPMTUD. This validation needs to be performed before the PLPMTU discovery method reacts to the PTB message.

  • A PTB message MUST NOT be used to increase the PLPMTU [RFC8201].
  • A PTB message could trigger a probe to test for a larger PLPMTU.

A valid PTB_SIZE is converted to a PL_PTB_SIZE before it is to be used in the DPLPMTUD state machine. A PL_PTB_SIZE that is greater than that currently probed SHOULD be ignored. (This PTB message ought to be discarded without further processing but could be utilized as an input that enables a resilience mode).

7. Probing and Congestion Control​

  • A PL MAY use a congestion controller to decide when to send a probe packet.

If transmission of probe packets is limited by the congestion controller, this could result in transmission of probe packets being delayed or suspended during congestion.

  • When the transmission of probe packets is not controlled by the congestion controller, the interval between probe packets MUST be at least one RTT.
  • Loss of a probe packet SHOULD NOT be treated as an indication of congestion.
  • Loss of a probe packet SHOULD NOT trigger a congestion control reaction [RFC4821].

This is because this could result in unnecessary reduction of the sending rate.

  • An update to the PLPMTU (or MPS) MUST NOT increase the congestion window measured in bytes [RFC4821].

Therefore, an increase in the packet size does not cause an increase in the data rate in bytes per second. A PL that maintains the congestion window in terms of a limit to the number of outstanding fixed-size packets SHOULD adapt this limit to compensate for the size of the actual packets.

The transmission of probe packets can interact with the operation of a PL that performs burst mitigation or pacing, and the PL could need transmission of probe packets to be regulated by these methods.

8. Probing and Flow Control​

Flow control at the PL concerns the end-to-end flow of data using the PL service. Flow control SHOULD NOT apply to DPLPMTU when probe packets use a design that does not carry user data to the remote application.

9. Shared PLPMTU State​

The PMTU value calculated from the PLPMTU MAY also be stored with the corresponding entry associated with the destination in the IP layer cache and used by other PL instances.

The specification of PLPMTUD [RFC4821] states, "If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described in Section 5.2) SHOULD be notified to make use of the new MTU". Such methods MUST be robust to the wide variety of underlying network forwarding behaviors. [RFC8201] Section 5.2 provides guidance on the caching of PMTU information and also the relation to IPv6 flow labels.

Design Principles​

In addition to the requirements above, the following principles are stated for design of a DPLPMTUD method:

1. Data Segmentation​

  • A PL MAY be designed to segment data blocks larger than the MPS into multiple datagrams.

However, not all datagram PLs support segmentation of data blocks.

  • It is RECOMMENDED that methods avoid forcing an application to use an arbitrary small MPS for transmission while the method is searching for the currently supported PLPMTU.

A reduced MPS can adversely impact the performance of an application.

2. MPS Primitive​

To assist applications in choosing a suitable data block size, the PL is RECOMMENDED to provide a primitive that returns the MPS derived from the PLPMTU to the higher layer using the PL. The value of the MPS can change following a change in the path or loss of probe packets.

3. Path Validation​

It is RECOMMENDED that methods are robust to path changes that could have occurred since the path characteristics were last confirmed and to the possibility of inconsistent path information being received.

4. Datagram Reordering​

A method is REQUIRED to be robust to the possibility that a flow encounters reordering or that the traffic (including probe packets) is divided over more than one network path.

5. Datagram Delay and Duplication​

The feedback mechanism is REQUIRED to be robust to the possibility that packets could be significantly delayed or duplicated along a network path.

6. When to Probe​

It is RECOMMENDED that methods determine whether the path has changed since it last measured the path. This can help determine when to probe the path again.

Implementation Considerations​

When implementing DPLPMTUD, consider:

  1. Efficiency: Avoid excessive probing that causes network overhead
  2. Robustness: Handle various network conditions and failure scenarios
  3. Interoperability: Compatibility with existing protocols and implementations
  4. Performance: Minimize impact on application performance

These requirements and principles ensure DPLPMTUD can work reliably under various network conditions.

Last updated on