[Taps] Review of taps-interface

Martin Duke <martin.h.duke@gmail.com> Thu, 06 August 2020 19:30 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 158213A0E36 for <taps@ietfa.amsl.com>; Thu, 6 Aug 2020 12:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qmswLYaIuyUI for <taps@ietfa.amsl.com>; Thu, 6 Aug 2020 12:30:04 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 139F33A0E31 for <taps@ietf.org>; Thu, 6 Aug 2020 12:30:04 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id l1so50792860ioh.5 for <taps@ietf.org>; Thu, 06 Aug 2020 12:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+1i3YG1wbVODUY3B9JlTxBISBWXruQO7zgSbFRtp8NM=; b=WR6grT64g6L1dDMrT0GDnHv5Q6RrZsr8Fh2WxSiYQyB3WNnZphnMNi+akoKiGmt7Ep eDrNJb3gQJWwhZwkNGco1jyGL5y4w8MmU/JjhEca3F+ErUwQW01mUO0hXVM8omb/qffp pie/Qssoqn1mkdxO2lbKOhH6wkGhzszTDJmvQVgjTODBWfXCXiDY5qqQc3x5EkW05qn6 SAvbM1LY98mg3pCKuAIqOjtLdw4HZwMS1510kD0CSD7Xo4ysfROOKQ7Ybkh9B9zlRJXU j4JgJeoyXY7oHacZ6Q9D5gr+o9re0NLQeVK4U4vY5rzWqca/cjKJXJi3cxbsR6Acvyhc ES6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+1i3YG1wbVODUY3B9JlTxBISBWXruQO7zgSbFRtp8NM=; b=oI4954cGghErmhWrWCieuBsHTJ+v/lcNsHgR/DWaMBUeJQqbrXyu1DygV+gYGvZTV4 16HRdgXkw/nwG+lkhbR9Sfb7yJXjkBH4iknKoszKePnsynlCPW1a24cxcrAOmYuCjJzA bb0kL7QXm9sY242We4sgi55Dl06R60Ln2XwLbNhudxqWPcI4FAROWcuQ/ptKZbBxU+dK vMkTWt6N7Vqv6Lp8KGrLK2AyFRM+sUiXJrJfiQAZHOWsJmgKPM0frsFetjPQKZmuUppu 4ljzDnLurbYxOyt9barG9gizbTtMQ9u/lrBkWej2b+67eS+LxtfV21/OlvYfw+TMUTlI ChMw==
X-Gm-Message-State: AOAM530RZflzBVDgDEmOgHvNLPSBdUigZam0r+jWPLQj4vyCasBP+0xt PciVBeCqqnb0B7dSKDskmHixTtJtuOSJgzmHmt9uq5xB44E=
X-Google-Smtp-Source: ABdhPJwZ3poEIYEtACwbNshf01sMkuRm521vb7Ld/QehGPMFJAZHLwrMUOQCqry2X8IZUYhgbNmE/YaQg/wVtdD6UhQ=
X-Received: by 2002:a05:6638:2391:: with SMTP id q17mr534715jat.31.1596742202994; Thu, 06 Aug 2020 12:30:02 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 6 Aug 2020 12:30:02 -0700
Message-ID: <CAM4esxQW704iLNnrOZX6uAMRPAWUqQzreMtyR2DuGPKnLgdKAQ@mail.gmail.com>
To: taps WG <taps@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ceb46005ac3a839a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/l_gnGXP9LFQVWV_pEbz1e9MoRqs>
Subject: [Taps] Review of taps-interface
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: Thu, 06 Aug 2020 19:30:06 -0000

Here is my promised "no prior knowledge" review of taps-interface. I
haven't filed issues for these yet, as I suspect some of these have already
been well-litigated there.

The only other draft I've read is taps-arch.

*High level comments*:

(1) I think this conceptually headed in the right direction.

(2) I found the relationship between streams and connections to be
extremely murky throughout the draft, and left it not really sure how I
would control a streamed transport.

Section 6.4 hints suggests that opening additional streams is an
alternative implementation of Clone() for transports that can do so. Does
this imply that if the peer stream limit does not allow new streams, the
transport should open a connection instead? How does
SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are
there two levels of listener: a stream listener and a connection listener?
How would opening "stream listeners" relate to the maximum number of
streams the peer could open (i.e. do I have to call listen() 8 times to
allow the client to open 8 streams)? Or are there no stream listeners and
these "connections" just sort of appear?

Skimming the -impl draft, I can see there's some text here but it is not
fitting together for me. There are at least three streamed transports and
it would be helpful to explain how the API conceptualizes this, perhaps in
a new section.

The next two major points are related to streams, so if I've missed
something important above they may be complete nonsequiturs.

(3) I'm not sure the priority framework really fits together.

Sec 6.4 says we 'should' do something that sounds like WFQ, but 7.1.5
allows the application to decide what happens. Meanwhile message priority
suggests a strict priority-based scheduler.

Meanwhile, in sec "Note that this property is not a per-message
override of the  connection Priority - see Section 7.1.3.  Both Priority
   may interact, but can be used independently and be realized by
   different mechanisms."

At the risk of overindexing on a partly-baked draft in httpbis, how would I
implement strict priority of HTTP/3 streams over a taps API that implements
QUIC? Would I need to request strict priority in *both* connection priority
and message priority? Or I guess connection priority would be sufficient?

(4) I found myself continually asking how I would implement foo-over-http/x
using this API, and very much stumbled over ambiguity regarding HTTP 1.1
pipelining. While it's certainly possible to order messages in the proper
way using this API, if I was writing this agnostically to HTTP version, it
appears it would gravitate to opening a pooled TCP connection for each
request/response if we ended up on HTTP/1 [because each request/response
would have a clone() call]. Maybe this is OK, but I found this conclusion
to be jarring.

*Specific comments*:

sec 4.2.2
"implementations MUST provide a
      method for the application to determine the entire set of possible
      values for each property."

Is this meant to be a requirement for a machine-readable API for learning
the enum, or merely a requirement for documentation? i.e. is it
satisfied if the values are in the man page or comments of the C header

sec 5.
I found it curious that there is no API here for registering callbacks, or
mention that this is a precondition to connection. Surely event handlers
are a prerequisite?

sec 5.1
I found it odd that there didn't appear to be any sort of formal list of
attributes of an endpoint, just some examples.

sec 5.2.7
I am not sure what this sentence means: "Disabling this property may enable
to control checksum coverage later."

sec 5.2.9
It would be helpful to say "Applications that neither prohibit nor require
congestion should query the result and disable their own congestion control
if present in the transport"

sec 5.2.12
Using temporary local addresses may break various mechanisms that prove
address ownership (e.g QUIC resumption tokens) and therefore impair
performance as the client has to re-verify its address.

sec 6.2
"After Stop() is called, the Listener can be disposed of." I don't
understand the difference between calling listener.stop() and simply
disposing of the object. Does this imply that there is a listener.start()
that allows a configured listener to resume?

sec 7.1.4
It would be helpful to clarify the relevance of control vs application data
in the idle timeout -- for various reasons, the connection could stay alive
regardless of how active the connection is (in fact, perhaps "keepalive" is
a generally useful notion that can be exposed in the API?)

sec 7.1.8
This section is missing a reference to minSendRate and minRecvRate

sec 7.1.9.
We're going to need an event for MTU changes. These can't simply be Send
errors because the Sent event might go first, or the transport might be
sending a probe with padding that doesn't correspond to a message.

sec 7.2
perhaps I'm not thinking of this correctly, but should there be a way to
query the peer-offered user timeout?

Reading the Sent event, I was pretty sure that reliable transports would
deliver the event until the ack arrived. But Sec 10 most definitely does
not say that. I would think that the ack would be a more useful signal, but
maybe I'm in the rough on this -- certainly many transport implementations
will not do this well.