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

[Gorry Fairhurst <[e-mail]>]

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

On 28/07/2021 05:30, Jen Linkova wrote:
> 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?
>