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

Michael Welzl <michawe@ifi.uio.no> Tue, 18 September 2018 09:53 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86121292AD; Tue, 18 Sep 2018 02:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxCmSJQSo90p; Tue, 18 Sep 2018 02:53:44 -0700 (PDT)
Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB7D130DDB; Tue, 18 Sep 2018 02:53:44 -0700 (PDT)
Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g2ChS-00032l-M9; Tue, 18 Sep 2018 11:53:42 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g2ChR-0002wf-Td; Tue, 18 Sep 2018 11:53:42 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <CABcZeBPUnscqAGxhmyWNPHCmN1aaV1fu-_nzAGW0zXPh-rApEQ@mail.gmail.com>
Date: Tue, 18 Sep 2018 11:53:41 +0200
Cc: draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, The IESG <iesg@ietf.org>, Theresa Enghardt <theresa@inet.tu-berlin.de>, "taps@ietf.org" <taps@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1B9F6CF-EF5B-48BB-94FE-F81A10F7DAE7@ifi.uio.no>
References: <153681690194.9412.2624965951701043464.idtracker@ietfa.amsl.com> <EB9548E6-D68F-4F98-A5C1-301A59568E05@ifi.uio.no> <CABcZeBP7+2v=e-1BxWvU0-JJ4-3dgLn=C1H9QMmHJ2fE3U1KZw@mail.gmail.com> <63AEF680-16FB-4BED-BAD1-3796B8B01D6F@ifi.uio.no> <CABcZeBPJa7QHpCpXVaKZ14La=iMJYVF_a0FpuhN5Sj5z+d3h2g@mail.gmail.com> <572DC009-AC72-4984-8087-627859EED2BA@ifi.uio.no> <CABcZeBPXiCOpFcDf_GtwT6A05-CSWaOSotwrEnx=haLmdAOfxA@mail.gmail.com> <CE4D125B-C115-451B-ABBE-60E491FFAEC6@ifi.uio.no> <CABcZeBPUnscqAGxhmyWNPHCmN1aaV1fu-_nzAGW0zXPh-rApEQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no;
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: ED16EE6FF3E71A849FA2712B86E71258F5BE6E1C
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/UOQPhKbCONQaw9wfoKy3v_C_o9k>
Subject: Re: [Taps] Eric Rescorla's No Objection on draft-ietf-taps-minset-08: (with COMMENT)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 09:53:47 -0000

Done, with version -10 (just submitted).

Cheers,
Michael


> On 17 Sep 2018, at 21:30, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> That SGTM....
> 
> -Ekr
> 
> 
> On Sun, Sep 16, 2018 at 5:04 AM, Michael Welzl <michawe@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.
> 
> 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
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps