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
