Done, with version -10 (just submitted). Cheers, Michael
> On 17 Sep 2018, at 21:30, Eric Rescorla <[email protected]> wrote: > > That SGTM.... > > -Ekr > > > On Sun, Sep 16, 2018 at 5:04 AM, Michael Welzl <[email protected]> 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 > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
