(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.
pgpxjTZIVJbX3.pgp
Description: PGP signature
_______________________________________________ pmtud mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pmtud
