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

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-taps-minset-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


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:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4808



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.

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.


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.


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?


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


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.