Subject: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 09 Apr 2020 04:31:29 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-tsvwg-datagram-plpmtud-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Firstly I would like to say thank you for writing this document.

I have a general concern, not specifically with this document, but with the
overall complexity of the solution.  I.e. the algorithm that is described has
to contend with a lot of unreliable information (e.g. are packets dropped
because of congestion or some other routing failure, hard to know whether PTB
messages can be relied upon etc), there are also several different ways that
the probes can be sent etc.

Not the subject of this document, but it feels like life could be significantly
simpler if somehow there was a mechanism to getting a set of agree a set of
defined minimum PLPMTU that network may support.  E.g. perhaps 1280, 2000,
4000, 8000, 16000 octets.   My assumption here is that the underlying core link
MTUs would be higher to cope with header overheads.

A few comments on specific sections of the document:

1) I would include PTB in the terminology section.

3. Features Required to Provide Datagram PLPMTUD

Most of the the requirements in this section use RFC 2119 language, but a few
don't:

   7.   Probing and congestion control: The decision about when to send
        a probe packet does not need to be limited by the congestion
        controller.  When not controlled by the congestion controller,
        the interval between probe packets MUST be at least one RTT.  If
        transmission of probe packets is limited by the congestion
        controller, this could result in transmission of probe packets
        being delayed or suspended during congestion.

Rather than "does not need to be limited", would this be better stated as 
"SHOULD NOT be limited" or "MAY not be limited"?

   11.  Probing and flow control: Flow control at the PL concerns the
        end-to-end flow of data using the PL service.  This does not
        apply to DPLPMTU when probe packets use a design that does not
        carry user data to the remote application.

The second sentence could be stated something like:

"Flow control MUST NOT apply to DPLPMTU when probe packets use a design that
does not carry user data to the remote application"

5.1.2.  Constants

   MIN_PLPMTU:  The MIN_PLPMTU is the smallest allowed probe packet
      size.  For IPv6, this value is 1280 bytes, as specified in
      [RFC8200].  For IPv4, the minimum value is 68 bytes.

Does it really make sense to probe for a path MTU of 68 bytes.  Would it make
sense for applications to be able to control the MIN_PLPMTU that they find
acceptable?  E.g. if IPv6 has this at 1280 and QUIC has uses 1280, perhaps many
applications/implementations would like to use 1280 as a reasonable lower bound
rather than 68 bytes?

---

From: "Black, David" <[email-masked]>
Date: Thu, 9 Apr 2020 13:46:53 +0000

Hi Robert,

> MTUs would be higher to cope with header overheads.

That would indeed be nice, but the plethora of tunnels and encapsulations in use suggests that boundary effects could result in the packet size settling to an MTU considerably smaller than possible.  For example, suppose that the underlying link is sized to support a 4000 byte MTU with some set of headers to which a tunnel that the link designers didn’t consider adds 64 bytes - having the MTU drop to 2000 bytes would not be a good result.

Thanks, --David (as an individual)

> -----Original Message-----
> From: Robert Wilton via Datatracker <[email-masked]>
> Sent: Thursday, April 9, 2020 7:31 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; Wesley Eddy; [email-masked]
> Subject: Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-
> 19: (with COMMENT)
> 
> 
> [EXTERNAL EMAIL]
>

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 9 Apr 2020 10:13:54 -0700 (PDT)

> That would indeed be nice, but the plethora of tunnels and encapsulations in use suggests that boundary effects could result in the packet size settling to an MTU considerably smaller than possible.  For example, suppose that the underlying link is sized to support a 4000 byte MTU with some set of headers to which a tunnel that the link designers didn?t consider adds 64 bytes - having the MTU drop to 2000 bytes would not be a good result.

I would like to point out that this *is* done in implementations to
hunt for an MTU.  From FreeBSD sys/netinet/ip_icmp.c:
/*
 * Return the next larger or smaller MTU plateau (table from RFC 1191)
 * given current value MTU.  If DIR is less than zero, a larger plateau
 * is returned; otherwise, a smaller value is returned.
 */
int
ip_next_mtu(int mtu, int dir)
{
        static int mtutab[] = {
                65535, 32000, 17914, 8166, 4352, 2002, 1492, 1280, 1006, 508,
                296, 68, 0
        };

IIRC the current Path MTU code in FreeBSD would infact land on a
2002 byte MTU for a TCP connection going through the tunnel that David
describes above by the nature of how it works.

-- 
Rod Grimes                                                 [email-masked]

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 9 Apr 2020 18:57:33 +0100

Yes, I think a table of common values would be cool. I suspect the 
values you refer to are from RFC 1191. These may now be rather historic: 
I doubt if the "arpanet" MTU which I recall was 1006, is such a helpful 
number, neither likely 68 or 508?. I would love people to come-up with 
new measurement data to tell us what the prevelent PMTUs are and where - 
and how best to search to find them: There also many ways you could 
perform the search algorithm. That sound's like something exciting for 
future MAPRG sessions:-).

Gorry

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 9 Apr 2020 22:12:23 -0700 (PDT)

> values you refer to are from RFC 1191. These may now be rather historic: 
                          ^^^^^^^^^^^^^^
The comment above them clearly states that.

> number, neither likely 68 or 508?.

1006 is from RFC 1055 - SLIP
508 is from RFC 1051 - Arcnet

I believe that 68 is there as the original IP minimal MTU, which I do
believe is still valid for ipv4.  I know the 296 was commonly used
for SLIP and/or PPP 256 payload + 40 header bytes.)

Here is one of the most complete tables I could find:
https://books.google.com/books?id=0IzfDQAAQBAJ&pg=PA240&lpg=PA240&dq=common+mtu+sizes+296&source=bl&ots=4_Of3fGewa&sig=ACfU3U2BIhuOddVngU--PUHTq1eZfWuucA&hl=id&sa=X&ved=2ahUKEwiTxqLvit3oAhVBGzQIHYjDC6wQ6AEwCHoECA0QMw#v=onepage&q=common%20mtu%20sizes%20296&f=false

> I would love people to come-up with 

One could alter the source code such that rather than doing the
table driven hunt for a working MTU it did some form of binary
search, and then report that data.  Run it on planetlab against
against an alexa list of web sites and you could get a pretty
good view of the server side path MTU.  Not sure how to try and
gather data from the "consumer" side.

Rod

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 10 Apr 2020 08:38:12 -0500

So, I hadn't looked at https://tools.ietf.org/html/rfc1191 in a VERY long
time, so thank you, Rod, for nudging me to do so.

> > values you refer to are from RFC 1191. These may now be rather historic:

"rather historic" is more than kind. The table on page 16 is a fairly
encyclopedic list of link layer technologies in common use in 1990, which
should surprise no one. Yeah, we assume 1500 works most of the time now,
but revisiting what's no longer in common use ("token bus") and what's
commonly encountered now (common MTU sizes in various commonly-used
tunneled paths, perhaps) is likely worth doing, at some point.

> > new measurement data to tell us what the prevelent PMTUs are and where -

Yes.

> gather data from the "consumer" side.

Interestingly, I note that strategy was considered in RFC 1191 (on page 7),
along with a bit of explanation:

   A more sophisticated approach is to do a binary search on the packet
   size.  This converges somewhat faster, although it still takes 4 or 5
   steps to converge from an FDDI MTU to an Ethernet MTU.  A serious
   disadvantage is that it requires a complex implementation in order to
   recognize when a datagram has made it to the other end (indicating
   that the current estimate is too low).  We also do not recommend this
   strategy.

(Of course, it's interesting to consider the definition of "complex in
1990, so MAYBE the decision would go the other way 30 years later? :-)

   One strategy that appears to work quite well starts from the
   observation that there are, in practice, relatively few MTU values in
   use in the Internet.  Thus, rather than blindly searching through
   arbitrarily chosen values, we can search only the ones that are
   likely to appear.  Moreover, since designers tend to chose MTUs in
   similar ways, it is possible to collect groups of similar MTU values
   and use the lowest value in the group as our search "plateau".  (It
   is clearly better to underestimate an MTU by a few per cent than to
   overestimate it by one octet.)

So, echoing the excellent points above (I hope),

ISTM that asking people to poke at this and report back in MAPRG is an
excellent idea. Depending on whether there are still "relatively few MTU
values in use" or not, it might then be useful to consider either updating
the table of commonly-used values, or saying "binary search will probably
work fine now".

ISTM that this draft doesn't need to wait for that investigation - this
text in
https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-19#section-5.3.2
seems to leave the search strategy up to implementers, and a better search
strategy wouldn't affect this text, that I can see:

5.3.2.  Selection of Probe Sizes

   The search algorithm determines a minimum useful gain in PLPMTU.  It
   would not be constructive for a PL sender to attempt to probe for all
   sizes.  This would incur unnecessary load on the path.
   Implementations SHOULD select the set of probe packet sizes to
   maximize the gain in PLPMTU from each search step.

   Implementations could optimize the search procedure by selecting step
   sizes from a table of common PMTU sizes.  When selecting the
   appropriate next size to search, an implementer ought to also
   consider that there can be common sizes of MPS that applications seek
   to use, and their could be common sizes of MTU used within the
   network.

So, thanks for the opportunity to start my day reading an old RFC written
by smart people and published in the same year I was setting up my first
TCP/IP LAN, and please continue this conversation as appropriate ("Do The
Right Thing")

Best,

Spencer

> > >> That would indeed be nice, but the plethora of tunnels and
> encapsulations in use suggests that boundary effects could result in the
> packet size settling to an MTU considerably smaller than possible.  For
> example, suppose that the underlying link is sized to support a 4000 byte
> MTU with some set of headers to which a tunnel that the link designers
> didn?t consider adds 64 bytes - having the MTU drop to 2000 bytes would not
> be a good result.
> > >>> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > >>> "Flow control MUST NOT apply to DPLPMTU when probe packets use a
> design
> > >>> that
> > >>> acceptable?  E.g. if IPv6 has this at 1280 and QUIC has uses 1280,
> perhaps
> > >>> many
> > >>> applications/implementations would like to use 1280 as a reasonable
> lower
> > >>> bound
> > >>> rather than 68 bytes?
> > >>>
> > >>>
> > >>
> > >>
> >
>
> --
> Rod Grimes
> [email-masked]
>
>

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 10 Apr 2020 17:02:00 +0300

> On 10 Apr, 2020, at 4:38 pm, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> ISTM that asking people to poke at this and report back in MAPRG is an excellent idea. Depending on whether there are still "relatively few MTU values in use" or not, it might then be useful to consider either updating the table of commonly-used values, or saying "binary search will probably work fine now".

In connection with this, it's perhaps worth noting that some applications won't need to establish the precise MTU, only the minimum number of fragments they need to use for their jumbo datagram.

For example, a 10,000 byte IPv4 packet can fit through a 1500-byte MTU path in seven 1446-byte fragments, but not in six 1684-byte fragments.  (The calculation is different for IPv6 due to the larger headers.)  Refining this distinction further only becomes relevant when datagrams of different sizes have to be sent over the same path, or when a stream transport is involved so that testing specific divisors is not helpful.

So a variety of search algorithms may be useful in different circumstances.

 - Jonathan Morton

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 10 Apr 2020 09:48:36 -0500

Hi, Jonathan,

On Fri, Apr 10, 2020 at 9:02 AM Jonathan Morton <[email-masked]>
wrote:

> In connection with this, it's perhaps worth noting that some applications
> won't need to establish the precise MTU, only the minimum number of
> fragments they need to use for their jumbo datagram.
>
> For example, a 10,000 byte IPv4 packet can fit through a 1500-byte MTU
> path in seven 1446-byte fragments, but not in six 1684-byte fragments.
> (The calculation is different for IPv6 due to the larger headers.)
> Refining this distinction further only becomes relevant when datagrams of
> different sizes have to be sent over the same path, or when a stream
> transport is involved so that testing specific divisors is not helpful.
>

Thank you for pointing that out! I've also been ignoring jumbo frames,
which weren't a thing in 1990 because we were still trying to get Ethernet
to work well over coax, and I suppose there'd be some interaction there,
too.

> So a variety of search algorithms may be useful in different circumstances.

Yup. I hope the next stop is in MAPRG, because this does seem useful.

Best,

Spencer