Re: Éric Vyncke's No Objection on draft-ietf-6man-mtu-option-13: (with COMMENT)

[Gorry Fairhurst <[e-mail]>]

See below, marked GF+BH :

-------- Forwarded Message --------
Subject: Éric Vyncke's No Objection on draft-ietf-6man-mtu-option-13: 
(with COMMENT)
Resent-Date: Mon, 4 Apr 2022 06:25:37 -0700 (PDT)
Resent-From: [e-mail]
Resent-To: [e-mail], [e-mail]
Date: Mon, 04 Apr 2022 06:25:37 -0700
From: Éric Vyncke via Datatracker <[e-mail]>
Reply-To: Éric Vyncke <[e-mail]>
To: The IESG <[e-mail]>
CC: [e-mail], [e-mail], 
[e-mail], [e-mail], [e-mail], 
[e-mail]


Éric Vyncke has entered the following ballot position for
draft-ietf-6man-mtu-option-13: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-mtu-option/



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

Thank you for the work put into this document. I am all in favour of 
extending
IPv6 with extension headers, and any system to improve path MTU detection is
helpful (esp. in data center at the beginning).

Let me also apologise to Bob, Gorry, and the 6MAN WG as I could have 
sent those
comments during the WGLC...

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Ole Trøan for the shepherd's write-up including the
justification for the intended status as experimental. You may also expect a
INT directorate review by David Lamparter later.

I hope that this helps to improve the document,

Regards,

-éric

What about multicast traffic ? Can this HbH option be used ? How can several
answers be combined ? As the intended status is "experimental", this is not
blocking but close to be a DISCUSS-level point though.

GF: There would be additional considerations about scaling responses and 
how to aggregate responses, with all the usual multicast design caveats 
and the question of what is best at what scale. We expect this is best 
handled as a separate short draft, should someone find a use for a 
multicast case.  We could add text to explicitly say that we do not 
specify the multicast use in the document.

======

I think it is OK to say that an experimenter could
permit this for multicast with CAVEATs: First, understanding that each 
endpoint
will reply, and that therefore a multicast destination should randomly 
delay their
reply to ensure that large numbers of replies are not received in a 
short interval.
Second, that the source needs a way to combine multiple different 
replies. As in
other multicast methods, this will require a decision of whether to 
accept and use
the lowest detected minMTU,or whether to then trigger a control protocol 
action
to expell members of the group with an unacceptably low MinMTU. These 
tradeoffs
and the security implications are expected to depend on the design of 
the multicast
transport being used, and the size of the group. They are not discussed 
in this
document.

I think all we should say is this draft is focused on Unicast.


## Abstract

Just wondering whether "node" should be used instead of "host" in "along the
forward path between a source host to a destination host" (also in other 
places
in other sections). Of course, nothing prevent a router to act as a host. §9
uses "node" and not "host" ;-)

GF+BH: We prefer not to make this change, because RFC8200 says:

node a device that implements IPv6.

router a node that forwards IPv6 packets not explicitly
addressed to itself. (See Note below.)

host any node that is not a router. (See Note below.)

Our intent is that this be sent and received by hosts. I think it’s 
clearer to continue to use host.

## Section 1.2

Suggest removing the note about RFC 2460 as 8200 has been published for 
years
now.

GF+BH: We think there is some value in keeping this history.

Even if mostly obvious, please expand "HBH" at first use.
GF+BH: Will do

## Section 6.1

For a router not configured for HbH-processing: why only "SHOULD ignore" ?
Either exception use case(s) should be provided or a "MUST NOT" and 
"MUST" (for
forward) be used.

GF+BH: The SHOULD language doesn’t work perfectly here.
I guess it's really a statement of fact "will ignore". Not sure it is 
worth changing.

Why does a router "SHOULD" only update and not "MUST" ? This is an 
experimental
document and not a proposed standard one so little reason to be 
ultra-cautious.
If "SHOULD" is kept, then when can/should a router deviate from the update
action ?

GF+BH:: We are happy to say MUST, i.e.if it implements this RFC it needs to.

Is the "Discussion" part still relevant at this stage (IESG evaluation) ? Or
should it be moved to the "experiment success evaluation" part ?

GF+BH: Either way for us. We will remove it.

Can the router apply sampling/rate limiting on those packets ?

GF+BH: It can, if used carefully. The result is loss, which might impact 
usefullness, but ought not
impact the correct function. Do we need to add something?

## Section 6.2

"This cached value can be used by other flows that share the host's 
destination
cache." is hard to parse and possibly incorrect (as missing the egress
interface), suggest to use "other flows to the same destination and same 
egress
interface" ?

===

GF+BH: Probably good to clarify. Indeed,it needs to be balanced with my 
ECMP text
added to 8201 that warns that paths are not just identified by address 
(see below)

If it was not an experimental document, I would probably have raised a 
blocking
DISCUSS (sorry Bob & Gorry), usually ECMP is done on the 5-tuple, so using
different layer-4 ports could end up in slightly different paths with 
different
MTU (section 5.2 of RFC 8201 is a little better, recommend referring to 
it ? --
it is only referred to in § 6.3.4).

GF+BH: We agree. It's important it is used to *initialise* a probe with 
the expected PMTU
size, and that the option is not to blindly used to set the PMTU, 
because the actual
PMTU can depend on the forwarding path for the flow, which can be 
influenced by
port information, flow lable, and other information besides the 
destination address.

Please expand "PL"

GF+BH: Will Fix - > PL = Packetization Layer.

"When requested to send an IPv6 packet" how ? and who request such an 
action ?
My major concern is whether it is a per packet or per "connection" 
request as
using a 8-byte MTU in a data packet actually reduces the useful MTU by 8 
bytes.
A forward reference to §6.3.1 would be beneficial.

GF+BH: My take is the transport has to generate the reply.

Bullet #3, it is unclear what "This" means.

GF+BH: Whoops we wanted to remove this bullet: /3. This sends a response 
probe back to source/.

===
## Section 6.3

"Using a PMTU Probe" is it the HbH option described in this document ? 
If so,
then propose being clear or introduce the synonym earlier in the text.

GF+BH: Transport guy problem, mea culpa...we should have explained "a 
PMTU Probe".

We suggest a complete replacement:

PLPMTUD use probe packets for two distinct functions:
• Probe packets are used to confirm connectivity. Such probes can be of 
any size
up to the PLPMTU. These probe are sent to solicit a
response use the path to the remote node. These probe can carry this HBH 
option,
providing the final size of packet does not exceed the current PLPMTU.
After validating that the packet orignates from the path
(section 4.6.1), the PLPMTUD method can use the reported size from the 
HBH option as
the next search point when it resumes the search algorithm.
(This use resembles the use of the PTB_SIZE information in section 
4.6.2of [RFC8889

• A second use of probe packets is to explore if a path supports a 
packet size greater than the current PLPMTU. If this probe packet is 
successfully delivered (as determined by the source host), then the 
PLPMTU is raised to
the size of the successful probe. These probe packets do not usually set 
the HBH option. See section 1.2 of [RFC8899].

Section 4.1 of [RFC8899] also describes ways that a Probe Packet can be 
constructed, depending on whether the probe packets carry application data.

• The PMTU Probe can be sent on packets that include application data, 
but needs to be robust to potential loss of the packet (i.e. with the 
possibility that retransmission might be needed if the packet is lost).

• Using a PMTU Probe on packets that do not carry application data will 
avoid the need for loss recovery if a router on the path drops packets 
that set this option. (This avoids the transport needing to retransmit a 
lost packet that includes this option.) This is the normal default 
format for both uses of probes.

===

## Section 6.3.2

Just wondering how different this method is wrt to ICMP-based PMTUD as the
5-tuple must also be present (albeit no data).

GF+BH: Not sure what to write in the ID, but the real benefit of PLPMTUD 
is it can avoid blackholing of data by PMTUD relying on ICMP,without 
regressing to using a minPMTU.

The drawback of PLPMTUD is it can require cycles of pobing using 
sacrifical packets to be sure the PMTU is not going to be blackholed, 
and the larger the PMTU above the default PMTU, the larger the number of 
RTT cycles, and hence the larger time to converge on safely using a 
larger PMTU. The HBH method seeks to complete in 2 RTT-cycles, ask for 
the PMTU across the path, confirm this size works.

Of course, if the discovered PMTU isn't actuallysupported by the path, 
then the HBH information did not help, and the larger probe either 
generates a PTB packet (one more RTT to converge) or is dopped. This 
takes at least one more cycle of probing to deduce the PMTU. It's hard 
work to robustly fix broken-ness.

GF+BH: Does this need a change to the text?

===

Also wondering how an upper-layer protocol (possibly QUIC in user space) 
could
signal to the PMTU cache (possibly in the kernel) to ignore a value. 
But, hey
this is all about experimenting ;-) And § 6.3.3 is going in more details 
about
where this data could be stored.

GF:That's the way (D)PLPMTUD is designed in QUIC, although I suspect many
QUIC flows simply don't update the IP layer PMTU cache at all, and 
simply use their
own ways to store previous results and figure out how to size their 
packets-pushing
a value bact to the IP layer cache may seem to have very little benefit.

===

## Section 6.3.4

Why not a "MUST" in "A source host SHOULD ignore a Rtn-PMTU value larger 
than
the MTU configured for the outgoing link." ?

GF+BH: MUST is good, will fix. We should have caught that.

===

# NITS

## Section 1.1

In scenario 2, s/considers the link to the destination host/considers 
the link
between R2 and the destination host/ ?

## Section 2

s/977K packets per second (pps)/977,000 packets per second (or 997 kpps)/

## Section 6.3.4

s/layer 2 device/layer-2 device/

## Section 8.1

s/Hop by Hop/Hop-by-Hop/

GF+BH: All good, will fix.
===

If these proposed changes seem OK (with any comments), please let us 
know if you'd like us to prepare a new revision or wait to collect 
further feedback from the review process.

Best wishes,

Bob & Gorry
(editors)