RE: Use cases for PMTUD and PLPMTUD (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)

["Templin, Fred L" <[e-mail]>]

Hi Fred,

> -----Original Message-----
> From: Fred Baker (fred) [mailto:[e-mail]]
> Sent: Friday, February 05, 2016 12:00 PM
> To: Bob Hinden
> Cc: Templin, Fred L; Ole Trøan; IPv6 List
> Subject: Re: Use cases for PMTUD and PLPMTUD (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)
> 
> 
> > On Feb 5, 2016, at 11:04 AM, Bob Hinden <[e-mail]> wrote:
> >
> > Instead continuing the debate over how RFC4821 should be cited in rfc1981bis, I am starting to think that a separate new document
> could discuss the relationship between the two approaches to learning the MTU, and make some recommendations on how they
> should be used together or separately.  Perhaps a BCP or update to Node Requirements.
> >
> > I don’t think this topic needs to be part of advancing RFC1981.
> 
> That thought has crossed my mind as well. It is unusual to have a specification describing one approach comment on a different
> specification about a different approach.
>
> If we were to write such a specification, what would it need to say?
> 
> I think the following would need to be present:
> 
> 1) pointers to RFCs 1981bis and 4821
> 2) reports of experience (not just concern) with each
> 2a) environments in which each works well
> 2b) demonstrated issues with each
> 3) recommendations about deployment
> 
> 2a for RFC 1981bis, would likely say that if ICMP PTB is not being blocked and a host is sending TCP segments that are too large, it
> quickly knocks them to a workable size. 2b for RFC 1981bis would likely say that if ICMP PTB is being blocked or spoofed, it doesn't
> behave well.
> 
> 2a for RFC 4821 should likely say that it achieves a reasonable MSS. 2b might observe that it is not guaranteed to do so quickly.

Another point that needs to be considered is interactions with multipath. With
RFC1981(bis), the path MTU will eventually converge to the minimum MTU of
all paths that contribute to the multipath. But, with RFC4821, each path in the
multipath would need to be tested independently, i.e., per-flow and not just
per-destination path MTU probing.

Implementations might approach this by starting the RFC4821 path MTU
probing process from scratch for every new TCP connection and not cache
the MTU discovered by previous connections. It would work, but could
result in lots of probing.

Thanks - Fred
[e-mail]

> As a recommendation, it seems like TCP should follow some kind of rule. There is an argument for sending segments in the initial burst
> of IW different sizes (including at least one derived from a 1280 byte MTU, one from a 1500 byte MTU, and one from a 9000 byte MTU,
> each less the sizes of any known headers) and either seeding the 4821 algorithm with the ack/sack response information, using the
> number found in a responding ICMP PTB, or, in the absence of an ICMP PTB, selecting the largest of those sizes that was acked or
> sacked. I'll bet Matt Mathis or one of his compadres would have a better approach.
> 
> We would also want to have an implementation report on the recommendations (at least one, ideally one used in each of several
> operational environments including virtualized data center, mobile wireless, wifi, broadband, and backbone).
>