Dear Eric, Thanks a lot for your comments! Answers below:
> Eric Rescorla has entered the following ballot position for > draft-ietf-taps-minset-08: No Objection > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > IMPORTANT > S 3.1. > - Is any of the following useful to the application? > * Specify checksum coverage used by the sender > * Specify minimum checksum coverage required by receiver > > Yes: UDP-Lite is preferred. > No: UDP is preferred. > > there seems to be something missing here wrt penetration rates. I.e., > SCTP (absent UDP) does not reliably work for any client behind NATs, > which means that it's not preferred for those clients regardless of > the other benefits in this tree. We added a statement about this below the decision tree. > COMMENTS > S 1. > of libraries to use this transport feature without exposing it, based > on knowledge about the applications -- but this is not the general > case). In most situations, in the interest of being as flexible and > efficient as possible, the best choice will be for a library to > expose at least all of the transport features that are recommended as > a "minimal set" here. > > What is the bar for the requirements here. I.e., do you believe that > all of these can be implemented with a standard sockets API. I don't fully get this - it CAN be implemented atop the standard socket API (cf. https://github.com/NEAT-project/neat), if that's what you're asking? > S 3. > > Based on the categorization, reduction, and discussion in Appendix A, > this section describes a minimal set of transport features that end > systems should offer. The described transport system can be > implemented over TCP. Elements of the system that are not marked > with "!UDP" can also be implemented over UDP. > > Does this mean over native UDP with no other session protocol. Because > you can have TCP over UDP. Native; we added a disclaimer about this at the end of the introduction. > S 3.2. > multiplexed as streams on a single SCTP association when SCTP may not > be available). The transport system must therefore ensure that > group- versus non-group-configurations are handled correctly in some > way (e.g., by applying the configuration to all grouped connections > even when they are not multiplexed, or informing the application > about grouping success or failure). > > How do you group connections in TCP? Or is this text saying it > doesn't? The text doesn't make any assumption about this being possible with anything but SCTP. This being said, I can't resist offering an answer (but that's out of scope of minset): https://ieeexplore.ieee.org/document/8406887/ > S 7.2. > o Request to negotiate interleaving of user messages > Protocols: SCTP > Automatable because it requires using multiple streams, but > requesting multiple streams in the CONNECTION.ESTABLISHMENT > category is automatable. > Implementation: via a parameter in CONNECT.SCTP. > > I'm not sure I follow how this is automatable. Is the argument that > SCTP will always do it, and so once you have asked for SCTP...? Actually, yes. We added this to the description of the implementation. > S 7.2. > > o Disable MPTCP > Protocols: MPTCP > Automatable because the usage of multiple paths to communicate to > the same end host relates to knowledge about the network, not the > application. > > I don't think I understand how this is automatable. Is the theory that > the host auto-negotiates MPTCP? But what if the app doesn't want it no > matter what. Then the application wants more than what this design of strictly "application-specific knowledge" is giving it. That's the trade-off here - there may be many reasons for applications to want things beyond this document, but if we weren't strict about these limitations, this would have hardly become a "minimal set". _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
