Document: draft-ietf-pmtud-method-10
Reviewer: Harald Tveit Alvestrand
Review Date: 2006-11-05
IETF LC End Date: 2006-10-26 (apologies for the lateness of this review)

Summary: Issues that need addressing.

Comments:

Big issues:

- Over-ambitious requirements language

Section 4 states:

   All Internet nodes SHOULD implement PLPMTUD in order to discover and
   take advantage of the largest MTU supported along the Internet path.

I think this is premature. We have not proved this protocol in the field.
That said, it is possible to configure it in such a way that it "does no 
harm" compared to current PMTUD - but we do not have the experience needed 
to recommend this yet. I suggest that this document does not state such a 
requirement at all.

- Performance problem for end-of-application-PDU probes

I am worried about the effect on performance in the case where a probe 
message is the last message sent on a TCP session for a given application 
layer action; in this case, the non-delivery detection will depend on 
timeout (section 7.5, "timeout failure"); I think this might happen even 
when there are a few trailing packets, but SACK is not in use, and the 
number of trailing packets is not enough to trigger a definite conclusion 
that the probe is lost. In request/response-oriented protocols, for example 
HTTP 1.1 sessions, this scenario might be encountered frequently, since 
request sizes are generally up to just a few Kbytes.

One possible mitigation strategy would be to modify the "overlapping" TCP 
algorithm given in section 10.1 to always retransmit the probe-unique data 
within some timeout on the order of (RTT+small delta) if unacknowledged; 
this would make the introduced delay at the higher levels bounded to a 
smaller quantity than a full timeout-driven retransmit would require, I 
think.

Nits:

The terminology section defines "router" in a way that would make an 
Ethernet switch with an IP stack a router. Please refer to some other 
definition; I think we have plenty of them lying around, including "router 
requirements" (RFC 1812). Appending ", as described in [RFC1812]" to the 
definition would be enough.

Definition of "PTB" doesn't give the standard name for the IPv4 
"fragmentation needed" message. Code 4 is "fragmentation needed and DF set" 
in RFC 792; I think "fragmentation needed" is more standard terminology 
than "Can't fragment".

Section 4 requirements:

The "MUST enforce their MTU" is nonsensical to have here, I think. It is 
not a requirement on implementations of PLPMTUD. If you need to state this 
at all, phrase it as "This protocol assumes that all links enforce their 
MTUs".

The IPv4 requirement that says SHOULD use DF is, I think, already specified 
in other RFCs, so it's OK to repeat it; references to the preexisting 
requirement would be appreciated.

The "shared state" update of section 4 does not mention how the sender 
identifies that two connections traverse the same path; this is especially 
troublesome in the presence of NAT, where two connections to the same IP 
address might in fact traverse quite different links behind the NAT box, 
resulting in different MTUs. A forward reference to section 5.2, where this 
problem is addressed, would be a Good Thing; at least the "minimum learned" 
requirement should be mentioned.