Ivan Beschastnikh wrote:
[snip]
Thanks for the nits. Will fix.
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.
Yes, "known" and "estimate" are the same thing. :) We'll fix this language.
What this is trying to say is that most of the time, if you are sending
a datagram larger than eff_pmtu, then the host should fragment it.
However, if you are sending a probe, you need the ability to indicate
this to the lower layers, so that it doesn't get fragmented.
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?
You're certainly correct, and it does merit some discussion in the
document. Specifying exactly what to do feels like a systems problem (a
little out of scope). There's a trade-off between sharing information
for better performance, and trust between applications/users on the same
system.
Thanks for the input.
-John
_______________________________________________
pmtud mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pmtud
