On Thu, Sep 13, 2018 at 7:34 AM, Michael Welzl <mich...@ifi.uio.no> wrote:
> 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? > How do you implement limits on retransmission rates with standard sockets? > > 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/ This is behind a paywall, but it appears to just be about congestion control, so perhaps there is some confusion about "grouping". I had read that as application visible grouping. Is that not what you mean? > > > > 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". > That's reasonable, but it seems like a somewhat confusing definition. -Ekr
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
