Re: Path MTU Hop-by-Hop Option

[Tom Herbert <[e-mail]>]

On Tue, Oct 23, 2018 at 8:14 PM, Fernando Gont <[e-mail]> wrote:
> On 10/24/18 3:57 AM, Tom Herbert wrote:
>> On Tue, Oct 23, 2018 at 11:03 AM, Fernando Gont <[e-mail]> wrote:
>>> On 10/17/18 6:49 AM, Carsten Bormann wrote:
>>>> On Oct 17, 2018, at 00:55, Bob Hinden <[e-mail]> wrote:
>>>>>
>>>>> This document specifies a new Hop-by-Hop IPv6 option that is used to
>>>>>   record the minimum Path MTU
>>>>
>>>> A while ago I proposed something similar to collect information about adaptation layer fragmentation MTUs (information about which is truly not available in any other way):
>>>>
>>>> https://tools.ietf.org/html/draft-bormann-intarea-alfi-04
>>>>
>>>> (I also only looked at the Internet layer here — leaving it as an exercise to put in transport/application protocol support.)
>>>>
>>>> After mulling an initial version of the proposal, there was pretty much consensus that hop-by-hop options were not really available on the Internet.  So I put in an alternative way to collect the information, see above if you are interested.  Then at some point SPUD came along and I was hoping that would lead to a framework within in which this information could be better handled.
>>>>
>>>> Maybe it’s time to pull the old draft out again.  The hop-by-hop option problem of course hasn’t gone away.
>>>
>>> IPv6 EHs are not readily available on the public IPv6 Internet. See
>>> RFC7872. While not included in RFC7872, my measurements indicate that
>>> the same applies even to IPsec EHs. :(
>>
>> Fernando,
>>
>> If I'm reading RFC7872 correctly, it is more accurate to say that the
>> drop rates for EH vary between 12% and 55% depending on type and
>> destination. We cannot say that EH always works on the Internet, but
>> neither is it correct to say that EH never works on the Internet.
>> Success rate is somewhere in between.
>
> Can you depend on something that fails in 10% (or more) of cases?
>
Well, aren't we also trying to depend on IPv6 itself which still has a
pretty high failure rate on the Internet? If we're restricted to only
use protocols that we can absolutely depend on to work then the only
choice is to use plain TCP over plain IPv4.

Also, I think "depend" is an interesting word in this context. By
definition the Path MTU option is an *option*, it cannot be required
for basic communications. No one can depend on it. It is an
optimization though, and as such does need to be used X% of the time
before it can be claimed to have value.

>
>
>> While the data in RFC7872 is objective, the conclusions being drawn
>> are not. I think there are two possible conclusions 1) Success rate of
>> EH is abysmal, EH is a failure and should be deprecated, and the
>> would-be contents of EH need to be moved to other layers somehow
>
> Tags aside, the reality is that if you need the the would-be contents to
> be reliable, you'd put them else where. Not that I like it... but
> whatever my personal taste is, it doesn't solve problems by itself.
>
The problem there is that no one has yet to define the alternative
that would work any better.

> (see what happened to ip options... the ipv6 eh case is worse).
>
>
>
>> 2) EH
>> support is less than desirable, but this is a current condition that
>> may be improve over time with new deployments, protocol
>> clarifications, definition of some "useful" options.
>
> Yes, it could improve. One never knows. Me, my gut feeling is that's
> unlikely.
>
>
>> IMO, until EH is
>> officially deprecated, it is entirely appropriate to define new uses
>> such as the Path MTU Option here.
>
> No matter how EHs are flagged, we're doing engineering. It works, or it
> doesn't. (as unfortunate as that may be).
>
I disagree that it has to be a global binary choice. Happy eyeballs
has shown how to deal with a protocol that has greater than zero, but
less than 100% support.

> To me, it all looks like they are reliable in controlled domains (within
> your network, where you control everything), but not elsewhere (public
> Internet)
>
That's not clear at all. For a small domain this might be plausible,
but for large sprawling domains like the big DC operators that use
multiple vendors it may or may not be true. Besides that, if the plan
is to only use features like EH in a controlled domain, then we need
to have an implementation at host to determine whether the destination
is in the controlled domain-- that is not necessarily easy to do. A
common solution should consider whether the feature is viable to each
particular destination.

>> Since we know up front that the
>> option might not always be viable on the Internet, the mechanism will
>> need a fallback;
>
> If the fall-back "just works" why not keep it simple?
>
Because fallback means we don't get the advantages of the feature.

>
>> but the need for a fallback is hardly unique: IPv6
>> falls back  IPv4 via happy eyeballs, UDP falls back to TCP when
>> firewalls block UDP, etc.
>
> I'd compare such a fall-back with e.g. retrying TCP connections without
> the ECN bits set. When doing the fall-back, you lose the benefits of
> ECN. - but I would expect that in most EH cases, loosig the
> functionality is not a viable option. e.g., what would the fall-back be
> for IPsec packets that get blackholed?   (I tel you *my* workaround: I
> tunel over TLS over a transport protocol.. don't even bother to try to
> do IPsec in the general case)
>
I think IPsec is an extreme. For other use cases of EH, particularly
DO and HBH, like Path MTU option, OAM, FAST the fallback is not to use
the option. Communication can proceed but advantages is lost possibly
resulting in a degraded mode of service relative to using the option.

> Just to make my point clear:not that I like the situation. BUt
> pretending it doesn't exist doesn't make it go away.

Agreed.

Tom

>
> Cheers,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>