Thanks Nick,
see below some observations.
On 09/02/2022 10:22, Nick Hilliard wrote:
Sheng Jiang via Datatracker wrote on 09/02/2022 06:29:
However, personally, I still not fully understand why this document are
intending for "experimental" and what would be the experiment range.
It seems
for me this mechanism are good enough to be a proposed standard to
persuade
people use it widely.
The draft proposes to add bottom-of-the-stack functionality to a 25yo
protocol, via a mechanism which is known to cause substantial packet
loss on production networks (see rfc7872).
Yes, loss of packets that carry the HBH PMTU was discussed. In
particular, loss of DPLPMTUD probes.
The reliability of the proposed mechanism was brought up several times
during discussion at WG level, e.g.
https://mailarchive.ietf.org/arch/msg/ipv6/QrfdW0omcigRdPy2VECa_82oAEY/
RFC8899, notes how that packet loss can impact classical PMTUD, but also
suggests how to handle this when using DPLPMTUD.
The difficulty with MTU negotiation is that getting the MTU wrong will
cause packet blackholing.
Much less so using DPLPMTUD?
In other words, the draft specifies a protocol enhancement whose
stated aims imply increased reliability, which depends on a mechanism
which is known to be highly unreliable in practice, and where
misconfiguration can cause serious reliability issues.
This is not P-S territory.
Wait, that's a pretty large brush being used here.
DPLPMTUD advocates the use of sacrificial probe packets, where failure
to deliver does not black-hole traffic If a sender sets a HBH option on
some of its probe packets, then those probe packets can be lost because
they carry this option - this would waste some network capacity with no
benefit. I'm not sure I'd see this as less reliable.
What misconfiguration could lead to "serious reliability issues"?
Separate to this, there is no running code that I'm aware of. There
are certainly no implementation reports.
There is no discussion in the draft of HBH reliability. It would be
appropriate if the ID quoted some of the EH reliability reports due to
operational concerns.
Nick
Gorry
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
