I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive. Feel free to forward to WG if desired.
Document: draft-ietf-pmtud-method-10
Reviewer: Harald Tveit Alvestrand
Review Date: 2006-11-05
IETF LC End Date: 2006-10-19 (apologies for the lateness of this review)
IESG Telechat date: Unknown
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
