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

[Michael Welzl <[e-mail]>]

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

You’re right about disabling MPTCP: typically the decision to do so would depend not only on knowledge about the net or OS, but also the type of data that an application has. Sticking with the specs as minset is doing, I searched, and found, in RFC 6897:

Section 3.1: "The following sections summarize the performance effect of MPTCP as seen by an application.”

and in there, we have things like:
**
   The benefits of MPTCP regarding throughput and resilience may come at
   some cost regarding data delivery delay and delay jitter.
(..)
   Applications with high real-time requirements might be affected by
   such a scenario.  One possible remedy is to disable MPTCP for such
   jitter-sensitive applications, either by using the basic API defined
   in this document, or by other means, such as system policies.
**

I guess the decision on whether to use MPTCP or not is actually a mix of knowledge about the network and app requirements. A better interface (IMO) would have the app tell its requirements, such that a system below it could automate its decision. I hope we get to that with draft-ietf-taps-interface, but that’s beyond minset - I think minset should therefore recommend exposure of “Disable MPTCP” and call it “Optimizing”, not “Automatable”. However, I think we should still not recommend exposure of adding and removing paths, as these really don’t make sense without net-specific knowledge.

Do you agree? If so, I’ll make that update in the next version - that was a great catch indeed!

Cheers,
Michael