Subject: [pmtud] PLPMTUD (draft-07) comments

From: Ivan Beschastnikh <[email-masked]>
Date: Tue, 11 Jul 2006 16:02:56 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: John Heffner <[email-masked]>
Date: Wed, 12 Jul 2006 11:26:55 -0400

Ivan Beschastnikh wrote:

[snip]

Thanks for the nits.  Will fix.

> 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.

> 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