Subject: [pmtud] wglc comments on plpmtud

From: Mark Allman <[email-masked]>
Date: Mon, 24 Jul 2006 13:59:14 -0400

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