[pmtud] wglc comments on plpmtud
Mark Allman <mallman@icir.org> Mon, 24 July 2006 18:28 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G55A7-0007Gf-TT; Mon, 24 Jul 2006 14:28:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G54iC-00012r-KM for pmtud@ietf.org; Mon, 24 Jul 2006 13:59:24 -0400
Received: from wyvern.icir.org ([192.150.187.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G54iA-0001Eg-62 for pmtud@ietf.org; Mon, 24 Jul 2006 13:59:24 -0400
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by wyvern.icir.org (8.12.11/8.12.11) with ESMTP id k6OHxGI3016642; Mon, 24 Jul 2006 10:59:20 -0700 (PDT) (envelope-from mallman@guns.icir.org)
Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 01AA677B3AB; Mon, 24 Jul 2006 13:59:15 -0400 (EDT)
To: pmtud@ietf.org
From: Mark Allman <mallman@icir.org>
Organization: ICSI Center for Internet Research (ICIR)
Song-of-the-Day: Lift Me Up
MIME-Version: 1.0
Date: Mon, 24 Jul 2006 13:59:14 -0400
Message-Id: <20060724175915.01AA677B3AB@guns.icir.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede
X-Mailman-Approved-At: Mon, 24 Jul 2006 14:28:14 -0400
Cc: mathis@psc.edu, matt@internet2.edu, jheffner@psc.edu
Subject: [pmtud] wglc comments on plpmtud
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: mallman@icir.org
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>
Content-Type: multipart/mixed; boundary="===============0584285531=="
Errors-To: pmtud-bounces@ietf.org
(Note, I am not on the PLPMTUD list so this post will likely have to be manually approved. If someone could do that, I'd much appreciate it.) Comments as I read through the latest I-D... I hope they help. allman Abstract: + Spell out PLPMTUD Section 2: + "Packet To Big" --> "Packet Too Big" Section 3: + You might note that the "MSS" is not a fixed value, but can change depending on the (IP or transport layer) options being applied to a given packet. + "Probe Size" ought to be more verbose. In particular "size of a packet" including what? All the other definitions are quite careful and this one is not. Section 5.4: + I didn't follow the last paragraph here. It doesn't seem right to me. It seems to me that if you do PLPMTUD with multicast you have two choices: (1) as outlined in the document, use the minimum PMTU found for the group or (2) split the group into sub-groups by PMTU size and send multiple times. It doesn't make sense to me that one multicast group could have multiple packet sizes. Section 6.1: + This is certainly not a tight specification. Maybe it doesn't need to be. However, there is really nothing in this document that really clearly says how to make sure that all loss that you're not reacting to (CC-wise) is caused by PLPMTUD. I wonder if you want something like RFC 3708 is what is really needed. I.e., this basically collects up a window worth of information and then decides that there was only reordering in the window and not loss. Similarly, you want to know that the only loss is of probe packets. Seems like this general guidance could be improved. Section 7. + I found 7.1 to be quite confusing. Why are there three variables? I sort of muddled through the rest of the document not knowing and trying to figure it out. I would have thought two of the variables were unchanging bounds on the PMTU (i.e., 68 or 1280 bytes on the low end and the local (or tunnel) MTU on the upper end). And, then the eff_pmtu was some varying quantity that floated between these bounds. But, the bounds change and it seems too complicated and confusing to me. Why do we need three variables that change? Maybe it is just a matter of better explaining it up-front... (And, this really led me to the point where I wasn't really sure if I grokked the overall algorithm because I didn't understand the preliminaries.) + E.g., I cannot figure out why you'd send a probe for less than eff_pmtu. + 7.6 needs standards language (SHOULD, MUST, etc.). It's odd that the language is all over the document except for when we get right down to the nitty-gritty. + I don't follow 7.6.2. When "probe failure" happens we set the high threshold to the size of the probe - 1. OK, I guess that makes a little sense... we know probe_size-1 is the highest the PMTU could be. But, again, I don't understand the case when eff_pmtu is larger than the probe size. And, then I don't understand why we'd set eff_pmtu to some size that we don't know works (probe_size-1). And, even more ... we then tell everyone else about the new eff_pmtu. I don't follow why we'd ever tell anyone else unless we found a new and valid PMTU. + In 7.6.3 the text suggest using a timeout of length "five times the non-timeout failure case". What is the "non-timeout failure case" time? This advice needs to have more around it. Section 10: + In 10.1 why is the text discussing things in terms of the MSS and not the MTU? Wouldn't the probe sizes be in terms of probe sizes and not the transport's MSS? + 10.2: It is not clear to me that a single loss "significantly" impacts flow performance when the transport is savvy enough to understand PLPMTUD and therefore not trigger congestion control when probes are lost. Suggest nuking the word.
_______________________________________________ pmtud mailing list pmtud@ietf.org https://www1.ietf.org/mailman/listinfo/pmtud
- [pmtud] wglc comments on plpmtud Mark Allman