Re: [pmtud] Comments in response to WGLC of PLPMTUD (rev-07)
John Heffner <jheffner@psc.edu> Wed, 12 July 2006 14:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0gAB-00069Y-GL; Wed, 12 Jul 2006 10:58:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0gAA-000694-Jo for pmtud@ietf.org; Wed, 12 Jul 2006 10:58:06 -0400
Received: from mailer1.psc.edu ([128.182.58.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0gAA-0000rk-8l for pmtud@ietf.org; Wed, 12 Jul 2006 10:58:06 -0400
Received: from [132.219.31.94] (h1f5e-net84db.lab.risq.net [132.219.31.94] (may be forged)) (authenticated bits=0) by mailer1.psc.edu (8.13.5.20060308/8.13.3) with ESMTP id k6CEw2nx006623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jul 2006 10:58:03 -0400 (EDT)
Message-ID: <44B50DF5.2070904@psc.edu>
Date: Wed, 12 Jul 2006 10:57:57 -0400
From: John Heffner <jheffner@psc.edu>
User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516)
MIME-Version: 1.0
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: Re: [pmtud] Comments in response to WGLC of PLPMTUD (rev-07)
References: <C0D2D845.5893%gorry@erg.abdn.ac.uk>
In-Reply-To: <C0D2D845.5893%gorry@erg.abdn.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: mathis@psc.edu, pmtud@ietf.org
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pmtud>
List-Post: <mailto:pmtud@ietf.org>
List-Help: <mailto:pmtud-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=subscribe>
Errors-To: pmtud-bounces@ietf.org
Thanks for reviewing. Comments inline below. Gorry Fairhurst wrote: > Please see comments below on the current draft. > > Best wishes, > > Gorry > > (Matt - could you post to the list if this "bounces", I'm working from my > laptop as I travel to the IETF and don't have access to my other "gf" > account from here). > > -------------------- > > * The title does not contain the abbreviation: PLPMTUD - this would greatly > help people searching titles to locate the RFC. > > * page 11, section 4, para 2. > "limited clock stabilities" > - the scenario and implications of this is not clear. There are devices that can deliver packets of a certain size with some probability depending on the packet's size and other factors such as temperature. Such devices should use an MTU sufficiently low such that they can reliably (for some definition of reliably) deliver packets of that size. The text could probably be a little clearer here. > * page 16, section 6.1, para 3. > - Mention is made of SACK blocks, it would be good to also cite RFC4341, > DCCP-CCID2: > DCP CCID 2 uses an ACK Vector that provides information equivalent > to that transmitted in a TCP SACK option. We haven't put anything specifically about DCCP in this doc. We might consider doing so (it wasn't ready yet before), but it could also be a separate draft. We can talk about this... > * page 18, section 7.2 (and section 7.7, 8) > - I like the use of 512 as an acceptable common minimum MTU in the current > IPv4 Internet, but this is by no means a required value. If PLPMTUD sets > this as a minimum, what can be done if the discovery fails to find a path > that supports this MTU? It would be a shame to have this "black-holed". > > Allowing PLPMTUD to drive the PMTU of a flow down to the minimum for IPv4 > appears to me to expose a much bigger DoS threat. IPv4 ICMP messages which > suggest such small MTUs may be a big performance hinderance to hosts and > routers. We're not specifying any real change to how ICMPs are processed. Most systems today have a configurable lower bound on MTU, and that's not likely to change. However, with black hole detection described in 7.7 (lowering MTU in response to persistent timeout), you can actually support even smaller MTUs while maintaining the limit on ICMPs. > One other option available only in IPv4, would be to enable "IP Router > Fragmentation - but clearing the DF bit". Is this good, evil or acceptable? I think that qualifies as evil. ;) Packets sent with the DF bit set usually have zeroed IP ID fields, and reassembly would be impossible. Unless the router also set the IP ID, but then you're getting yourself into a mess... per address-pair state, etc. in the router. > * Section 7.6. > - This section does not make use of RFC2119, it seems that some of these > cases should use "SHOULD" or "MUST". Was this intentional? Yes. We felt like 2119 language here was unnecessarily strict for most of this section, as it's describing a somewhat flexible method that might have room for future refinement. I think all the really critical stuff has 2119 language. > * Page 21, section 7.6.1, first para > - So what must the node do when the reported result of a probe is successful > for a smaller PMTU than that which is currently in use. Is this a case where > the probe should be treated as successful, but the probe value should be > ignored? In such a case, it wouldn't be entirely ignored -- you still set search_low, while eff_pmtu remains the same. So, it doesn't have an immediate observable effect, but you do make a state change. > * Page 27 > - I don't particularly like the idea of probing the return path MTU at the > same time as the forward path MTU (i.e. Using an ECHO mechanism). There does > not seem to be any need for a sender to know the MTU of the return path... > For example, a corner case in the use of ICMP-ECHO-REQUEST to probe for > bandwidth is that this actually performs a bi-directional test for the PMTU > probe size. Paths exist that have assymmetric properties (e.g. Scenarios > described in RFC3449), where the response to the probe mail fail, even > though the PMTU in the forward direction was accepted. Section 10.4 also > talks about the idea of probing the return path. Probing both paths is less than ideal, but is conservative in that if the probe succeeds, you know the forward path is capable. We view pings as a sort of last resort if you can't do anything else. > * Page 27, final para > (e.g., 1kBytes or less) > - Is this thinking directed to IPv4? > - Would this better be 512B for IPv4 and 1280 for IPv6 to be consistent with > earlier? This is describing an initial eff_pmtu, not a search_low (which would be 512 or 1280) like described in the initial values section. If you are using ipv6, something larger than 1k would be appropriate, so we could change the text to "(e.g., 1280 bytes or less)". OTOH, it's not unreasonable to try 1k regardless of protocol. It saves you from needing separate config values for both ipv4 and ipv6. This text is really only a hint, not specifying anything. We can try to clarify this better. > * Security Considerations > - See above. IMHO, it is worth stressing the performance vulnerability of > setting an outrageously small PMTU size in IPv4. > Possibly. We're not really specifying changes to the ICMP processing though, so that might not be in scope. I guess it couldn't hurt to mention it? Thanks again for the comments. Will pull in the nits and try to fix up some of the muddy parts. -John _______________________________________________ pmtud mailing list pmtud@ietf.org https://www1.ietf.org/mailman/listinfo/pmtud
- [pmtud] Comments in response to WGLC of PLPMTUD (… Gorry Fairhurst
- Re: [pmtud] Comments in response to WGLC of PLPMT… John Heffner
- Re: [pmtud] Comments in response to WGLC of PLPMT… Gorry Fairhurst