FWIW, On Sun, Sep 16, 2018 at 7:03 AM Michael Welzl <mich...@ifi.uio.no> 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. > Speaking as an individual contributor in PANRG, and not as an AD, I'm not sure that PANRG would be ready to recommend that yet, even with net-specific knowledge! Do you agree? If so, I’ll make that update in the next version - that was a > great catch indeed! > Speaking as the responsible AD, yes, it was, and thank you, Eric, for catching it. Spencer > Cheers, > Michael > > >
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
