Christian Hopps <[email protected]> wrote: >> Christian Hopps <[email protected]> wrote: >>>> * I'm glad you recommend PLMTUD, I suggest PMTUD is dead. How do >>>> use PLMTUD? Will you tell us later in the document, or is that new >>>> work? (does not look like you tell us) >> >>> I believed it was enough to just reference the mechanism (as we do >>> for PMTUD as well). This was added during the transport area review. >> >> PMTUD relies on ICMP to say "too big" >> >> PLMTUD relies on TCP to send a repeated ack (packet loss) to tell us >> that we guessed wrong. We now have RFC8899 too, but I don't know how >> to apply it, and I think that some advice is in order.
> +considered the more robust option. For PLMTUD, congestion control
> +payloads can be used as in-band probes (see [[Congestion Control
> +AGGFRAG_PAYLOAD Payload Format]] and [[RFC8899]]).
> Additionally a "P-bit" was added to the CC header so that loss of the
> in-band probes can be disregarded as loss-events by the CC algorithm.
I still don't really see enough explanation of:
1) what do my probe packets look like?
Can I, for instance, send regular traffic, padded to the extra size?
That's an optimistic view of things, but maybe appropriate.
How do I get positive response that it was accepted?
2) How do I learn about traffic that was dropped?
I'm on about this, because I think that PMTU issues are among the biggest
problem for IPsec.
If we can auto-tune the tunnel size, that's really a killer use.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
