Subject: Comments on draft-ietf-6man-mtu-option-05

From: Jen Linkova <[email-masked]>
Date: Wed, 28 Jul 2021 14:30:25 +1000

Bob, Gorry,

A few comments on the draft:

1)Section 4. Applicability Statements
"This Hop-by-Hop Option header is intended to be used in environments
such as Data Centers and on paths between Data Centers".

It might be just me but I find it a bit confusing. Are, for example,
enterprise networks, like Data Centers? I read it as 'networks under
single/coordinated administrative control' but I'm not sure.

2) Section 6.2.  Host Behavior
"When requested to send an IPv6 packet with the Minimum Path MTU
option, the source host includes the option in an outgoing packet.
   The source host SHOULD fill the Min-PMTU field with the MTU
   configured for the link over which it will send the packet on the
   next hop towards the destination host.  If this value is not updated,
   the field MUST be set to zero."

What are the cases when the host might not set Min-PMTU? "If the value
is not updated' sounds a bit confusing to me, to be honest. Also, it
creates a bit of an issue: the routers are requested to update the
Min-PMTU field only if the outgoing link MTU is less than the Min-PMTU
value. So, sending a packet with Min-PMTU = 0 would do nothing as no
router would ever update the field.
The destination host would get the zero value as well (and, as I can
see, the draft does not describe any special treatment for the '0' on
the receiver side).

Am I missing anything here? It looks like we shall either ensure that
the field is always initialized with the link MTU, or the router
behaviour shall be modified. The receiver shall ignore zero MTU as
well.

3)Packet Loss

-  IMHO it would be beneficial to discuss the packet loss scenarios a
bit more and provide more guidance when to set the option. As I've
mentioned earlier, setting it for TCP SYN might drastically increase
the chances for Happy Eyeballs fallback. I'm not sure what's the best
course of action - maybe setting it for the first packet after the
handshake?

- Another crazy idea: what about some kind of "happy eyeballs" for the
option and when the packet with the option is sent for the first time
- sending another one, w/o an option soon after? Or, if the packet was
a TCP one and wasn't ACKed - the stack MUST send the retransmit w/o
the option?

- The draft says 'this option is intended to be used in environments
such as Data Centers'. Do we want to discuss how we can achieve that
it's only used for some destinations and not for the others? So hosts
inside a DC can send the option towards destinations in another DC but
not towards Google, for example?

- The draft recommends suspending the option usage if an ICMPv6 error
message is received. Shall the host keep some state/do a kind of
exponential backoff based on the data about blackholed packets with
the option?

-- 
SY, Jen Linkova aka Furry

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 28 Jul 2021 11:11:34 +0100

Jen,

Thanks everso much, an extra pair of critical eyes is always really 
helpful.  Your comments are all helpful: to me this suggests some change 
of words is needed, and we'll go through each in turn when we get a 
moment and suggest clarifications (and maybe some changes to the way we 
describe the endpoint usage of the option).

We'll be in touch soon.

Gorry