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

[Eric Rescorla <[e-mail]>]

On Fri, Sep 14, 2018 at 12:18 AM, Michael Welzl <[e-mail]> wrote:

> > On 13 Sep 2018, at 20:24, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > On Thu, Sep 13, 2018 at 11:02 AM, Michael Welzl <[e-mail]>
> wrote:
> > Hi,
> >
> >
> >> > 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?
> >
> > It’s an SCTP feature (limiting the number of retransmissions is a part
> of its partial reliability, specified as one way of doing it in RFC 3758);
> when you fall back to TCP, you do nothing.
> >
> > In terms of the document, the following text in appendix A.1 says it:
> >
> >    o  Configurable Message Reliability
> >       Protocols: SCTP
> > (..)
> >       Implementation over TCP: By using SEND.TCP and ignoring this
> >       configuration: based on the assumption of the best-effort service
> >       model, unnecessarily delivering data does not violate application
> >       expectations.  Moreover, it is not possible to associate the
> >       requested reliability to a "message" in TCP anyway.
> >       Implementation over UDP: not possible (UDP is unreliable).
> >
> >
> > If that seems disappointing: the goal of this document was to describe
> what can be done while being protocol-independent and allowing to fall back
> to TCP, or even UDP in some cases. The minute you write code that checks if
> configuring retransmission limits is possible, you need to implement an
> exception for the TCP case. I’m not saying this is bad design at all, it
> just wasn’t the goal of the minset. This doesn’t mean that a TAPS system
> needs to be limited in this way - it’s just the minimum you can expect from
> it.
> >
> > I'm not disappointed, I'm just trying to figure out how to think about
> this API and its requirements.
> >
> > What does it mean to implement this API when you have a transport which
> doesn't support the feature? Just that you have an affordance that pretends
> to implement it but doesn't?
>
> Exactly - though "pretends to implement it" is maybe not how it would put
> it: no promises are made. An application says "these messages can be out-of
> order", or "these connections really belong together, with the following
> priorities between them", but the priorities are just a hint and might be
> ignored, and the messages may arrive in-order, nobody promised that there
> would NOT be ordering.
>

All I meant was that the API is a no-op.



> On TCP coupling:
> > I'd love to see the paper.
>
> I'll follow up in a separate email, with TAPS in cc because people there
> might find it interesting, but removing the IESG to reduce noise.
>

Thanks.


>> > 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.
> >
> > What is it that’s confusingly defined? “application-specific knowledge”?
> “Automatable"? Happy to fix if you tell me what.
> >
> > Automatable, I think.
>
> Okay, so this is what we have in the text:
>
> " The transport features of IETF transport protocols that do not
>    require application-specific knowledge and could therefore be
>    utilized by a transport system on its own without involving the
>    application are called "Automatable". "
>
> and "application-specific knowledge" is defined as "knowledge that only
> applications have."
>
> I'm guessing that the issue that you have with "automatable" is that it
> sounds too much as if the application's input really isn't needed here, no
> matter what. I'd like to use a "weaker" word in that sense... because of
> that, we once called it "Potentially automatable", but then that was too
> long and clumsy.
> Do you have any suggestions?
>

Not really. I guess the thing that I'm saying is that MPTCP is something
that the stack could automatically decide to use, but it can't
automatically decide *not* to use if the application wants that. That's
what's puzzling me about "automatable"

-Ekr

Cheers,
> Michael
>
>