> On Feb 26, 2021, at 12:21 PM, Michael Richardson <mcr+i...@sandelman.ca> > wrote: > > > 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?
This is what https://tools.ietf.org/html/rfc8899 <https://tools.ietf.org/html/rfc8899> documents. All that this document should do is provide the on the wire mechanism to send a probe packet and get a reply that it was received, as well as provide for not considering probe loss as loss events for CC (the p-bit). The CC header does this (the sender timestamp is echo'd back for RTT estimates). The implementation of RFC8899 can choose to send user data or not (RFC8899 recommends that one should avoid doing this if possible). Thanks, Chris. > 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: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
