Re: [Taps] Eric Rescorla's No Objection on draft-ietf-taps-minset-08: (with COMMENT)

[Michael Welzl <[e-mail]>]

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".