Christian Hopps <cho...@chopps.org> wrote: >> Christian Hopps <cho...@chopps.org> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec