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

[Eric Rescorla <[e-mail]>]

That SGTM....

-Ekr


On Sun, Sep 16, 2018 at 5:04 AM, Michael Welzl <[e-mail]> wrote:

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