Re: [Taps] Eric Rescorla's No Objection on draft-ietf-taps-minset-08: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Mon, 17 September 2018 19:31 UTC
Return-Path: <ekr@rtfm.com>
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 4B187130EC7 for <taps@ietfa.amsl.com>; Mon, 17 Sep 2018 12:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 OcwkfYYZgIZS for <taps@ietfa.amsl.com>; Mon, 17 Sep 2018 12:30:58 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FB6130EB7 for <taps@ietf.org>; Mon, 17 Sep 2018 12:30:55 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id 203-v6so14249764ljj.13 for <taps@ietf.org>; Mon, 17 Sep 2018 12:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nV4qNPGZCVkG6gA9PBQ1pgKzaprhKtkc8hyLN2fXmGw=; b=q8e9oLFAL9/NeyZ2D1EKfoPrLLCaCuJX0Ljr+NUDMq6Ks4KS08xF+Ra+67GDaWLjGr 021+XG0AsYy+N0JyFTI95KWeyJYTsztvRcbNZ3MydRBbQG2x/kFC1qFbpieSwr+3hnpi sLH4kEQ5DlIQ8vlgzheqB90sWQ41WnF2tSlERbKdAk6waVb5fDt1D2P78/b1Yiz6iVzP VqA9pnM3iStxLwvTQ0Yhd0GWaWt4i6mB575uT5Zjaa07rPwFD7BTpEZdGhso1PaCjy7R ZQgqz1PPMSqr8T38jL7jlpcPDZAibeOHhx69Lgfb8ftu3Z6k8iVAaKKptO4wIrqPD1tu KFeg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nV4qNPGZCVkG6gA9PBQ1pgKzaprhKtkc8hyLN2fXmGw=; b=l9Ab1Q5f/6hfqor+OSBPE+7erCbsXdFxinybpWYpN0NgtBr9YPQIubwN2DgO+ofDjh opMZ7gJi/n7IumSoEREjbUxZj+AunwZwZaytfQ4F4fOumN7beoClJDv89eGPnf2NRf3r moKtj4e+iimXEItFBg5X+eewdyDPbJGxwQmysyTGi3vg8iRLC8mYhX55MIqF3kLHabIC xU0etUWoPNjZikAl3ykqipmSOYrsdPkEHf3TxDHdJk1Xwd8zkz7uq92Ulx22UPiY/0hO NvimnF8a4eKzMTtHmuRUmPPxSfX6r0m1rrbF9HsPmLhY4r9xsVuJRVs3NabVt+dLdxVt OmEQ==
X-Gm-Message-State: APzg51Dlbh9r2dWS8jHinOHQqyCgNNuWV4BCoL9IXGLNB78VVwSKukmC RimgYwQ8lNO+NtZY7DTJM+RwonDjEhakB32jhENRyw==
X-Google-Smtp-Source: ANB0VdbVdIzzkFWykR5f1gPkD8tLydLfz3CoeGGBHGTeJ2zhbP4slZBFIIUHD5QdCHRR6ZiuORRmyUfGlaAPGbAmB5Q=
X-Received: by 2002:a2e:9c82:: with SMTP id x2-v6mr9140729lji.131.1537212653222; Mon, 17 Sep 2018 12:30:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab3:498d:0:0:0:0:0 with HTTP; Mon, 17 Sep 2018 12:30:12 -0700 (PDT)
In-Reply-To: <CE4D125B-C115-451B-ABBE-60E491FFAEC6@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 17 Sep 2018 12:30:12 -0700
Message-ID: <CABcZeBPUnscqAGxhmyWNPHCmN1aaV1fu-_nzAGW0zXPh-rApEQ@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
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-Type: multipart/alternative; boundary="00000000000023d0ff0576163673"
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/muVdInEwAXijpvvslOyx0cJCFWQ>
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: Mon, 17 Sep 2018 19:31:01 -0000
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] Eric Rescorla's No Objection on draft-ietf… Eric Rescorla
- Re: [Taps] Eric Rescorla's No Objection on draft-… Michael Welzl
- Re: [Taps] Eric Rescorla's No Objection on draft-… Eric Rescorla
- Re: [Taps] Eric Rescorla's No Objection on draft-… Michael Welzl
- Re: [Taps] Eric Rescorla's No Objection on draft-… Eric Rescorla
- Re: [Taps] Eric Rescorla's No Objection on draft-… Michael Welzl
- Re: [Taps] Eric Rescorla's No Objection on draft-… Eric Rescorla
- Re: [Taps] Eric Rescorla's No Objection on draft-… Michael Welzl
- Re: [Taps] Eric Rescorla's No Objection on draft-… Spencer Dawkins at IETF
- Re: [Taps] Eric Rescorla's No Objection on draft-… Eric Rescorla
- Re: [Taps] Eric Rescorla's No Objection on draft-… Michael Welzl