Subject: [tsvwg] Effect of TPB on PLPMTU in draft-ietf-tsvwg-datagram-plpmtud-03

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 11 Jul 2018 03:37:03 +0000

This came up in a discussion in QUIC WG.

The draft is very useful for its recommendations on the probing aspects of PLPMTUD.  Yet, it seems too "timid" in its recommendations regarding validated (and "not-validated") TPB messages.

The draft explicitly forbids TPB setting PLPMTU (even provisionally): "A validated PTB message MAY be used as input to the DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU" (section 5.1.5).  This seems to be in contradiction with section 5.4.3 that implies that a provisional reduction on PMTU is ok for QUIC: "Any reduction in PMTU due to a report contained in an ICMP packet is provisional until QUIC's loss detection algorithm determines that the packet is actually lost" (a quotation from quic-transport).  It also recommends discarding PTB messages "where there is insufficient ICMP payload" (section 4.3).

PTB is a common signal that is acknowledged by the draft and RFC4821 as useful for optimal performance.  The biggest problem with PTB signals on the Internet is not that they are lying but that they do not make it to the sender.  When they do make it to the sender (still a common occurrence), ignoring PTBs (or merely using them as a signal to start probing, per section 3.3) is likely to drive at least one RTT of data into an MTU blackhole.

Malicious PTB messages should be a concern, but if a PLPMTU > PTB_SIZE >= BASE_PMTU (or another value between BASE_PMTU and MAX_PMTU), I think it makes sense to set PLPMTU and PROBED_SIZE to PTB_SIZE (and begin PLPMTUD).  The upside, the common case, is avoidance of a blackhole for an RTT or more.  The downside, in case of a malicious PTB, is a minor and temporary decrease in throughput.  As an attack, it seems not worth the attacker's efforts (especially, if the attacker is powerful enough to fake validated PTBs).

I'd go further and claim that there should be such OK_PMTU between BASE_PMTU and MAX_PMTU to recommend setting PLPMTU = PROBED_SIZE = PTB_SIZE using "not-validated" PTB messages, if PLPMTU > PTB_SIZE  >= OK_PMTU.  All of the reasons above apply, especially since such PTB messages are common on the Internet today.  ("Not-validated" means that the message cannot be validated due to the lack of validating data or an API deficiency; it does not mean that a message has been proven Invalid.)

I am looking forward to feedback on this.

- Igor