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

[Eric Rescorla <[e-mail]>]

On Thu, Sep 13, 2018 at 7:34 AM, Michael Welzl <[e-mail]> 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