Just on the discovery of PMTU... On 23 May 2018, at 06:36, Michael Welzl <[email protected]> wrote:
>>> Section 3.2.3: Path MTU Discovery surprised me here. What does that mean? >> That DTLS relies on an application implementing PMTUD (as it’s over UDP), >> and then telling DTLS about it? Doesn’t DTLS do this on its own? Why not? >> Sorry for asking a DTLS question, surely it’s me… but just listing PMTUD as >> a dependency isn’t a good enough explanation, I think. >> >> Clients have to set the maximum DTLS fragment (record) size, as each record >> must fit within a single datagram. > > Oh, wow, so it is true -- you have to do PMTUD in your application to > properly use DTLS?? > Note the previous comment from Mikael Abrahamsson in his email about minset: > he wondered if a TAPS system should offer PMTUD. > If using DTLS is such a hassle, maybe the answer should be yes? (being > application-independent, for UDP, I think this could only be done with a > mechanism such as draft-ietf-tsvwg-datagram-plpmtud ) > Sorry for the digression! > > Cheers, > Michael That is fine - the reality is you do not need PMTUD. However, if you choose a low PMTU this impacts efficiency. If you use a larger PMTU - then you impact robustness - unless you provide black hole detection. That does not help efficiency, for that the endpoint would need to probe. If the transport system offered PMTUD the system could do this with the Apps blessing, but likely without the Apps involvement. The difference between tcp and udp is that the API needs to support this. This is needed for the stack to do PMTUD. Otherwise an app could ask the stack to do black hole detection. Some apps may instead just do all the PMTUD via an API. That is three ways of working. All of which can be used with Dplpmtud. Gorry _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
