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

Michael Welzl <michawe@ifi.uio.no> Fri, 14 September 2018 07:18 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 AAFD4130E12; Fri, 14 Sep 2018 00:18: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 DsmM7vYV5vtD; Fri, 14 Sep 2018 00:18:43 -0700 (PDT)
Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 919B1130DDB; Fri, 14 Sep 2018 00:18:43 -0700 (PDT)
Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g0iNF-0008F2-8V; Fri, 14 Sep 2018 09:18:41 +0200
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from <michawe@ifi.uio.no>) id 1g0iNE-000F4R-8g; Fri, 14 Sep 2018 09:18:41 +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: <CABcZeBPJa7QHpCpXVaKZ14La=iMJYVF_a0FpuhN5Sj5z+d3h2g@mail.gmail.com>
Date: Fri, 14 Sep 2018 09:18:39 +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: <572DC009-AC72-4984-8087-627859EED2BA@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>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.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: 700DC558A0BF08674D66446B42C90BFADE9BA43B
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/RvM1uv3oc5Zt77Z9ojhPIxXZFqs>
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: Fri, 14 Sep 2018 07:18:47 -0000

> On 13 Sep 2018, at 20:24, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Thu, Sep 13, 2018 at 11:02 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
> Hi,
> 
> 
>> > COMMENTS
>> > S 1.
>> >     of libraries to use this transport feature without exposing it, based
>> >     on knowledge about the applications -- but this is not the general
>> >     case).  In most situations, in the interest of being as flexible and
>> >     efficient as possible, the best choice will be for a library to
>> >     expose at least all of the transport features that are recommended as
>> >     a "minimal set" here.
>> > 
>> > What is the bar for the requirements here. I.e., do you believe that
>> > all of these can be implemented with a standard sockets API.
>> 
>> I don't fully get this - it CAN be implemented atop the standard
>> socket API (cf. https://github.com/NEAT-project/neat), if that's
>> what you're asking?
>> 
>> How do you implement limits on retransmission rates with standard sockets?
> 
> It’s an SCTP feature (limiting the number of retransmissions is a part of its partial reliability, specified as one way of doing it in RFC 3758); when you fall back to TCP, you do nothing.
> 
> In terms of the document, the following text in appendix A.1 says it:
> 
>    o  Configurable Message Reliability
>       Protocols: SCTP
> (..)
>       Implementation over TCP: By using SEND.TCP and ignoring this
>       configuration: based on the assumption of the best-effort service
>       model, unnecessarily delivering data does not violate application
>       expectations.  Moreover, it is not possible to associate the
>       requested reliability to a "message" in TCP anyway.
>       Implementation over UDP: not possible (UDP is unreliable).
> 
> 
> If that seems disappointing: the goal of this document was to describe what can be done while being protocol-independent and allowing to fall back to TCP, or even UDP in some cases. The minute you write code that checks if configuring retransmission limits is possible, you need to implement an exception for the TCP case. I’m not saying this is bad design at all, it just wasn’t the goal of the minset. This doesn’t mean that a TAPS system needs to be limited in this way - it’s just the minimum you can expect from it.
> 
> I'm not disappointed, I'm just trying to figure out how to think about this API and its requirements.
> 
> What does it mean to implement this API when you have a transport which doesn't support the feature? Just that you have an affordance that pretends to implement it but doesn't?

Exactly - though "pretends to implement it" is maybe not how it would put it: no promises are made. An application says "these messages can be out-of order", or "these connections really belong together, with the following priorities between them", but the priorities are just a hint and might be ignored, and the messages may arrive in-order, nobody promised that there would NOT be ordering.


On TCP coupling:
> I'd love to see the paper.

I'll follow up in a separate email, with TAPS in cc because people there might find it interesting, but removing the IESG to reduce noise.



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

Cheers,
Michael