Dear Mikael, Thanks a lot for reading, and thanks for your feedback! Answers in line:
> On May 11, 2018, at 1:26 PM, Mikael Abrahamsson <[email protected]> wrote: > > On Thu, 10 May 2018, Aaron Falk wrote: > >> Please read the draft and send comments to the list. This document is >> planned to be an Informational RFC. Statements along the lines of 'ready to >> publish' are also welcome. > > I've never read this document before, but read all the main body now. I did > not read all of the appendices. > > I did read A3.7 plus search for my pet peeve, which is trying to avoid IP > level fragmentation in communication plus handling path MTU blackhole > detection/mitigation. > > It seems lots of what I was looking for is here. The main body (minus > appendices) is easy to read and makes sense to me. I guess some details will > be cleared up in a future document that actually specifies the APIs and how > they would look. A3.7 at least gives possibility for applications to get PMTU > information, that's great. > > However, I couldn't find exactly how an application can be helped to > determine the actual working PMTU by specifying some kind of probe packets > that are devoid of actual "content", ie padded to max PMTU size? This document is strictly based on RFCs 8303 and 8304. These RFCs list what TCP, MPTCP, SCTP, UDP, UDP-Lite and LEDBAT offer, according to their spec. From this, on top of UDP, you’d have to implement this functionality by yourself inside your application, and using the UDP functionality that’s covered by draft-ietf-taps-minset you can do this on top of a transport system that only offers this “minimum set". However, this is only a minimal set of functionality that transport systems should expose; it is quite okay for a transport system to offer functionality that goes beyond it. > At least that would be understood by two TAPS systems for the protocols where > this isn't already implementable in other ways (I imagine this can be done > for SCTP and TCP without the application having to get much involved, but > will be harder for UDP). Yes - > So to implement some kind of "test if PMTU actually works" TAPS functionality? This is a question about draft-ietf-taps-interface, and for the current version of this draft, the answer is no. Note that a TAPS transport system can be deployed one-sided, i.e. there’s no signaling side-channel or anything; so for some questions, such as “does the PMTU actually work”, only your application may know the answer. This said, we could think about supporting draft-ietf-tsvwg-datagram-plpmtud in draft-ietf-taps-interface. Given that Gorry is an author of both drafts, I expect him to have an opinion on that :) > I know I'm late in the game here and haven't followed TAPS closely, so > something like this might already be in there, but it's decided to not go > into the minimum requirements? This minimum set is only based on what the examined protocols can currently do. If people think a transport system should be able to do more, I’d suggest to directly propose this for draft-ietf-taps-interface. > Anyhow, for a first-time reader, this document seems fine and nothing jumped > out to me as being wrong in it (of the parts that I read). Good to know, thanks! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
