Hello,
I just read the draft-ietf-pmtud-method-07 document and have a few
comments and questions.
pg1, 2nd paragraph: "If can be configured to perform" should read "*It*
can be.."
pg3, 5th paragraph (last paragraph in section 1): "..and draw heavily
RFC1191 and .." should read "...and draws heavily *on* RFC..."
pg16, section 7.1: When you define search_low you say its equal to
useful probe size minus one. Useful probe size is somewhat ambiguous- do
you mean a probe size that hasn't been verified yet ie. the link might
or might not support an MTU size of this value?
pg17, last paragraph: "..and rely ICMP PTB.." should read "and *..to*
rely *on* ICMP PTB.."
pg 18, fourth paragraph: "..and per per-route configuration" should read
"and *per route* configuration"
In section 8 you say that if an application sends a datagram larger than
the "known path MTU," the datagram should be fragmented in the host's IP
layer. In section 9, you say that a third mode is needed which allows
the application to send datagrams that are larger than the current
"estimate of the path MTU". Are "known path MTU" and "estimate of the
path MTU" the same thing and if not, then is "estimate of path MTU" an
application level estimate rather than a system level "known" value
(since you're talking about application level PMTUD in this section).
Also, I don't see how the recommendation for IPv4 implementations from
section 8 differs from mode #1 from section 9, paragraph 2.
Along the previous comment, I see an unmentioned security repercussion
of the scheme described in section 9, second to last paragraph where
application level PLPMTUD results can be cached at IP layer by the OS or
the system level vars for the method can be directly updated by the application.
Wouldn't this mechanism effect other applications on the host that are
doing PLPMTUD of their own or sending over the same path? Particularly
if a rogue application decides to set the MTU for the first hop to a
very low value to starve the bandwidth of other applications on
the same host, how can this scenario be avoided, is this beyond the scope of
this document?
many thanks,
ivan.
_______________________________________________
pmtud mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pmtud
