Subject: [Taps] Fwd: New Version Notification for draft-gjessing-taps-minset-05.txt

From: Michael Welzl <[email-masked]>
Date: Tue, 20 Jun 2017 14:21:25 +0100

Dear group,

We just updated the minset document. Important changes are:
- the minset itself is now presented early, all the long boring text about how stuff was derived has been moved to an appendix
- a first stab at an abstract API representation of the minset is now included!

Cheers,
Michael & Stein

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-gjessing-taps-minset-05.txt
> Date: June 20, 2017 at 2:09:24 PM GMT+1
> To: Michael Welzl <[email-masked]>, Stein Gjessing <[email-masked]>
> Resent-From: <[email-masked]>
> 
> 
> A new version of I-D, draft-gjessing-taps-minset-05.txt
> has been successfully submitted by Michael Welzl and posted to the
> IETF repository.
> 
> Name:		draft-gjessing-taps-minset
> Revision:	05
> Title:		A Minimal Set of Transport Services for TAPS Systems
> Document date:	2017-06-20
> Group:		Individual Submission
> Pages:		44
> URL:            https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt
> Status:         https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
> Htmlized:       https://tools.ietf.org/html/draft-gjessing-taps-minset-05
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05
> 
> Abstract:
>   This draft recommends a minimal set of IETF Transport Services
>   offered by end systems supporting TAPS, and gives guidance on
>   choosing among the available mechanisms and protocols.  It is based
>   on the set of transport features given in the TAPS document
>   draft-ietf-taps-transports-usage-05.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Theresa Enghardt <[email-masked]>
Date: Mon, 26 Jun 2017 16:18:48 +0200

Hi,

when reading the minset draft, I stumbled over a couple of points. Some
of them may be nits and/or obvious to everyone except me, but I thought
I'd offer them as feedback.

Section 2 (Terminology): Would it make sense to define several more
terms here, such as Flow, Flow group, Message and Frame? While reading
the rest of the draft I was, e.g., wondering if a "TAPS flow" is the
same as "Connection" defined in Section 2 or something else. E.g., in
Section 3.1 the draft talks about how to create a TAPS flow and at least
for me it would be helpful to read a description of what a TAPS flow
actually is beforehand.

Section 3.1 (Flow Creation, Connection and Termination), second
paragraph: "A created flow can be queried for the maximum amount of data
that an application can possibly expect to have transmitted before or
during connection establishment."
I had trouble understanding this sentence, as it was not immediately
obvious to me that it is possible to send data before a connection is
established. Maybe it would be helpful to first state that this is a
feature that some protocols have.

Section 3.2 (Flow Group Configuration): Is it also possible to configure
these features on individual flows? Only if they do not have a group? (I
had the same question again later at the beginning of Section 4.)

Section 3.3 (Flow Configuration): At this point I was also wondering how
to configuring a flow to be, e.g., reliable. As reliability is one of
the most obvious transport features for me, I would find it useful to
make this explicit. It is not configured per flow, but per message,
right? So an application can send both reliable and unreliable messages
in one flow, but it does not communicate this through the TAPS API at
flow creation time, but only later when it actually sends the messages?

Section 3.4.1 (The Sender): This section talks about messages and
per-frame properties. Is a message the same as a frame here?

Features that are optional - So are these still mandatory features to
have in the API (which I thought the minset was) but then they do not
have to be implemented, i.e., actually do something?

Section 4 (An Abstract MinSet API): Do I have to create a flow-group-id
explicitly or is the flow-group-id just the flow-id of a previous flow?
In other words, are the flow-id and the flow-group-id the same number
space or are they distinct?

Best,
Theresa

On 20.06.2017 15:21, Michael Welzl wrote:
> - the minset itself is now presented early, all the long boring text
> about how stuff was derived has been moved to an appendix
>> *From: *<[email-masked] <mailto:[email-masked]>>
>> *Subject: **New Version Notification for
>> draft-gjessing-taps-minset-05.txt*
>> *Date: *June 20, 2017 at 2:09:24 PM GMT+1
>> *To: *Michael Welzl <[email-masked] <mailto:[email-masked]>>,
>> Stein Gjessing <[email-masked] <mailto:[email-masked]>>
>> *Resent-From: *<[email-masked] <mailto:[email-masked]>>
>>
>>
>> Name:draft-gjessing-taps-minset
>> Revision:05
>> Title:A Minimal Set of Transport Services for TAPS Systems
>> Document date:2017-06-20
>> Group:Individual Submission
>> Pages:44
>> URL:
>>            https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt
>> Status:
>>         https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
>> Htmlized:
>>       https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05
>> Diff:
>>           https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>
>
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Mon, 26 Jun 2017 17:37:38 +0200

Hi Michael,
Hi Stein,

I also read through the draft (now more than once) and have some questions and comments.
I hope not to open old rat-holes with this…

Sec 1 (Intro) 

   The number of transport features of current IETF transports is large,
   and exposing all of them has a number of disadvantages: generally,
   the more functionality is exposed, the less freedom a TAPS system has
   to automate usage of the various functions of its available set of
   transport protocols.  Some functions only exist in one particular
   protocol, and if an application would use them, this would statically
   tie the application to this protocol, counteracting the purpose of a
   TAPS system.  Also, if the number of exposed features is exceedingly
   large, a TAPS system might become very hard to use for an application
   programmer.  Taking [TAPS2] as a basis, this document therefore
   develops a minimal set of transport features, removing the ones that
   could be harmful to the purpose of a TAPS system but keeping the ones
   that must be retained for applications to benefit from useful
   transport functionality.

I am somewhat unsure if a TAPS system really should withhold an application from, e.g., using TCP specific features if it has strong evidence that the other endpoint will be TCP only? 

I agree that an application using TAPS should make use of automation when possible to avoid ossification, but is excluding applications that need protocol specific functionality much more dangerous as it requires a non-TAPS API to be present to service them?

   This "minimal set" can be implemented one-sided with a fall-back to
   TCP: i.e., a sender-side TAPS system can talk to a non-TAPS TCP
   receiver, and a receiver-side TAPS system can talk to a non-TAPS TCP
   sender.  For systems that do not have this requirement,
   [I-D.trammell-taps-post-sockets] describes a way to extend the
   functionality of the minimal set such that several of its limitations
   are removed.
I am glad to see that fallback is addressed, but why exclusively to TCP and not TCP or UDP – whatever is more applicable?

I also don’t see any reason why a system like post sockets shouldn’t support fallback. If using something happy eyeballs to check what protocols are available (biased by preference)m there is no reason why supporting a fallback ha to limit functionality.

Sec 2.3 (Flow Group Configuration)

Does the "capacity profile” only apply to a flow group or can it also be applied on a per-message basis?
If this is only intended to imply the DSCP value, a message would be a much better scope, e.g. for protocols that multiplex multiple kinds of message within a single flow/flow group.

Same applies to more values. Does it make sense to make them configurable on multiple levels?

Sec. 4

CONFIGURE_URGENCY (flow-group-id [scheduler] [capacity_profile]
   [low_watermark])

Do these three really belong together or are this these rathe three more or less independent configuration variables?

   CONNECT (flow-id dst_addr)

   Connects a flow.  This primitive may or may not trigger a
   notification (continuing LISTEN) on the listening side.  If a send
   precedes this call, then data may be transmitted with this connect.

   PARAMETERS:
   dst_addr:  the destination transport address to connect to

Might be only a knit but this looks very TCP centric for me – how would a usage example for "UDP connect” (which is somewhat of a contradiction anyway) – maybe I only dislike connect here…

Maybe this also needs what types of dst_addr might take - do I have to think this something like a sockaddr_t or as a host / service pair? The latter is much more useful for automation.

AVE!
  Philipp S. Tiesel / phils…

> On 20. Jun 2017, at 15:21, Michael Welzl <[email-masked]> wrote:
> 
> Dear group,
> 
>> From: <[email-masked] <mailto:[email-masked]>>
>> To: Michael Welzl <[email-masked] <mailto:[email-masked]>>, Stein Gjessing <[email-masked] <mailto:[email-masked]>>
>> Resent-From: <[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt <https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-05.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ <https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/>
>> Htmlized:       https://tools.ietf.org/html/draft-gjessing-taps-minset-05 <https://tools.ietf.org/html/draft-gjessing-taps-minset-05>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05 <https://datatracker.ietf.org/doc/html/draft-gjessing-taps-minset-05>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05 <https://www.ietf.org/rfcdiff?url2=draft-gjessing-taps-minset-05>
>> 
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 Jun 2017 19:32:47 +0200

Hi,

and thanks a lot for your comments!

Answers in line:

> On Jun 26, 2017, at 4:18 PM, Theresa Enghardt <[email-masked]> wrote:
> 
> Hi,
> 
> when reading the minset draft, I stumbled over a couple of points. Some of them may be nits and/or obvious to everyone except me, but I thought I'd offer them as feedback.
> 
> Section 2 (Terminology): Would it make sense to define several more terms here, such as Flow, Flow group, Message and Frame? While reading the rest of the draft I was, e.g., wondering if a "TAPS flow" is the same as "Connection" defined in Section 2 or something else. E.g., in Section 3.1 the draft talks about how to create a TAPS flow and at least for me it would be helpful to read a description of what a TAPS flow actually is beforehand.

Good input, will do!
(the answer is: it can be a (TCP) connection, a stream of an (SCTP) association, an (SCTP) association, …   so i thought it’s good to use a new word; yet it does fit the definition of a connection in section 2)

> Section 3.1 (Flow Creation, Connection and Termination), second paragraph: "A created flow can be queried for the maximum amount of data that an application can possibly expect to have transmitted before or during connection establishment." 
> I had trouble understanding this sentence, as it was not immediately obvious to me that it is possible to send data before a connection is established. Maybe it would be helpful to first state that this is a feature that some protocols have.

ACK, will do, thanks!

> Section 3.2 (Flow Group Configuration): Is it also possible to configure these features on individual flows? Only if they do not have a group? (I had the same question again later at the beginning of Section 4.)

These things apply to a group only, because in case a flow becomes a stream of an association, the protocol can only apply them to all  (e.g., change the timeout - you can’t do that for one stream of an SCTP association only). I’ll try to clarify this in the text.

> Section 3.3 (Flow Configuration): At this point I was also wondering how to configuring a flow to be, e.g., reliable. As reliability is one of the most obvious transport features for me, I would find it useful to make this explicit. It is not configured per flow, but per message, right? So an application can send both reliable and unreliable messages in one flow, but it does not communicate this through the TAPS API at flow creation time, but only later when it actually sends the messages?

Exactly. Though here lies a fault - if this is not communicated at all, the TAPS system may choose UDP, and then a sender decides for reliability….  bad!  Good catch !  Will try to fix.

> Section 3.4.1 (The Sender): This section talks about messages and per-frame properties. Is a message the same as a frame here?

Yes - but it’s another fault, I tried to use frame everywhere as the new term here just to avoid making a connection between “message” and an SCTP “message”  (can be the same but doesn’t have to be). So, use of message is a mistake. Will fix!

> Features that are optional - So are these still mandatory features to have in the API (which I thought the minset was) but then they do not have to be implemented, i.e., actually do something?

Hm, I see them as optional in the API… I don’t think we can truly “mandate” a minset - it is meant to be a set of functions that you will never be able to use unless you offer them in an API in one way or another.
In that sense, offering e.g. "Get max. transport frame size that may be sent without fragmentation from the configured interface” is just an optimization, because a user could just as well decide to forbid fragmenting and test various frame sizes … a less efficient way of implementing PMTUD atop minset than by using this extra functionality. So, I thought it’s less important to offer this extra...

Then again since nothing is *truly* mandatory maybe we should just skip saying “this and this is optional”.

> Section 4 (An Abstract MinSet API): Do I have to create a flow-group-id explicitly or is the flow-group-id just the flow-id of a previous flow? In other words, are the flow-id and the flow-group-id the same number space or are they distinct?

They’re distinct. The group is just a number to group flows, and flows must have identifiers too - so you can have group 1 containing flows 1, 2, 3 and group 2 containing flows 1, 2, 3.
I’ll try to make the text clearer, thanks!

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Mon, 26 Jun 2017 23:00:44 +0200

Hi Philipp,

Thanks a lot for your comments!  Definitely not rat-holing, you ask some quite interesting questions - it’s great to get some discussion on this!

My answers are in line:

> On Jun 26, 2017, at 5:37 PM, Philipp S. Tiesel <[email-masked]> wrote:
> 
> Hi Michael,
> Hi Stein,
> 

Let me give you an SCTP example: "Specifying a "payload protocol-id" (handed over as such by the receiver)”.  This is actually just a mechanism to send an out-of-band number that’s logically associated with an SCTP association. I wouldn’t think it’s the world’s most useful mechanism, either… but: if you use this, any chance of falling back to TCP flies out the window. I.e.: if SCTP doesn’t work, the TAPS system fails. You write about TCP; this is a bit of a special case, because it’s the protocol that we chose to be able to fall back to - so forever binding an application to TCP won’t make the TAPS system fail. It will, however, make it less flexible, so I don’t think it’s advisable.

Note these are all informational documents, there’s no TAPS “police” - if you implement a TAPS system that goes against this rule this is still a good way forward!  But I think having this word of caution against such protocol-specific functions here makes sense.

> I agree that an application using TAPS should make use of automation when possible to avoid ossification, but is excluding applications that need protocol specific functionality much more dangerous…

I don’t know - maybe we should discuss this based on concrete cases. What functionality are you missing?
To me, if possible, the better thing to do would be to express this functionality abstract enough so it doesn’t get in the way of a TAPS system’s flexibility.

> I am glad to see that fallback is addressed, but why exclusively to TCP and not TCP or UDP – whatever is more applicable?

That’s a tricky one. At some point, when designing this, I thought of addressing both … and that would have made the draft even longer and the story even more complex. This was my main motivation for TCP-only  :)
Also, TCP does suit for many things - even UDP applications won’t “break” with TCP (actually some UDP apps such as Skype *do* fall back to TCP), but most TCP apps would “break” with UDP.

> I also don’t see any reason why a system like post sockets shouldn’t support fallback. If using something happy eyeballs to check what protocols are available (biased by preference)m there is no re…

I disagree with the second sentence, but maybe this is a misunderstanding, as there are multiple degrees of freedom here.
If “fallback” is only about the protocol on the wire, not about the system on the other end, then there is no limitation: you can define pretty much any protocol you wish atop UDP.
However, fallback as in the minset draft requires only a one-sided change - i.e., a minset client is able to talk to a TAPS-ignorant TCP server.

post-sockets is somewhere in between: it does assume a post-socket system on both ends (e.g., to guarantee that the receiving application is informed about message boundaries), but most of it can probably be implemented with existing protocols.

> If this is only intended to imply the DSCP value, a message would be a much better scope, e.g. for protocols that multiplex multiple kinds of message within a single flow/flow group.

First: it’s not only intended to imply the DSCP value - I tried to make things a tiny bit more abstract and uniform by inventing this transport feature that encompasses the DSCP but also e.g. the choice of LEDBAT or not, or controlling Nagle.
Second: conceptually I agree that a message would be a better scope if it was only the DSCP (but it isn’t - and e.g. switching to LEDBAT clearly isn’t a per-message thing), but even for the DSCP this doesn’t seem doable with TCP, or with SCTP, where the DSCP is a parameter of a “peer address”, i.e. related to an association: https://tools.ietf.org/html/rfc6458#section-8.1.12 <https://tools.ietf.org/html/rfc6458#section-8.1.12>

> Same applies to more values. Does it make sense to make them configurable on multiple levels?

What do you mean?

> Do these three really belong together or are this these rathe three more or less independent configuration variables?

Oh, that was just an effort to group them somehow. We could just as well have a big “CONFIGURE” call that lets you configure anything, I just felt it’s a bit more organized this way. To me, these fit together, but I don’t have a very strong opinion about this.

> Might be only a knit but this looks very TCP centric for me – how would a usage example for "UDP connect” (which is somewhat of a contradiction anyway) – maybe I only dislike connect here…

It’s not a contradiction - CONNECT just creates a context, e.g. for configuration transport features (see draft-ietf-taps-transports-usage-udp ). In the minset, a flow can also be a stream of an SCTP association, in which case opening flow #2 and #3 of an association doesn’t actually produce any effect on the wire - just as with UDP.

> Maybe this also needs what types of dst_addr might take - do I have to think this something like a sockaddr_t or as a host / service pair? The latter is much more useful for automation.

Ah, I see - “transport address” is defined in the list in the usage draft, but not in the minset draft. I think that’s a mistake, based on copying an older version of this list. Sorry!
From the usage draft:

***
   Transport Address:  the combination of an IP address, transport
      protocol and the port number used by the transport protocol.
***

Cheers,
Michael

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 27 Jun 2017 11:23:29 +0200

Hi Michael,

> On 26. Jun 2017, at 23:00, Michael Welzl <[email-masked]> wrote:
> 
> Hi Philipp,
> 
>> On Jun 26, 2017, at 5:37 PM, Philipp S. Tiesel <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Michael,
>> Hi Stein,
>> 

Ok - this case looks as useful as TCP urgent data – I agree recommending against using such mechanisms.

> Note these are all informational documents, there’s no TAPS “police” - if you implement a TAPS system that goes against this rule this is still a good way forward!  But I think having this word of…

I think this is a little more complex… If you want a TAPS system to fully replace other Socket APIs, I assume it should also make protocol features available, that are nor portable across protocols. I agree that these features are
a) not part of a minimal set b) no “first class citizens” c) recommended against using. 
The question is whether this discussion should go into this or another draft.

> To me, if possible, the better thing to do would be to express this functionality abstract enough so it doesn’t get in the way of a TAPS system’s flexibility.

I definitely see OOB mechanisms as discussed above and path management in MPTCP and SCPT. 
The latter is a good candidate for abstract terms and automation, but there might also be use cases for which a more concrete, protocol independent API to bind data to certain paths is needed.
For OOB mechanisms, there might be use of some special flags to the send_frame and recv_frame calls that are a) protocol specific, b) cause an error if called on a flow using the wrong protocol and c) are recommended against using.

> Also, TCP does suit for many things - even UDP applications won’t “break” with TCP (actually some UDP apps such as Skype *do* fall back to TCP), but most TCP apps would “break” with UDP.

For doing this, you would have to move the reliable/unreliable decision up to the "Flow Group” level…
But finally, I guess it is needed at both levels. In case “unreliable” it is set at "Flow Group” level, all messages will be unreliable, if set at message level, the single message is sent unreliable if supported by the underlying protocol.

> post-sockets is somewhere in between: it does assume a post-socket system on both ends (e.g., to guarantee that the receiving application is informed about message boundaries), but most of it can p…

Oh, I never read that from the Post Socket publications. But I guess we should discuss this with Brian how much he has Post Socket to “Legacy” communication in mind.

>> Same applies to more values. Does it make sense to make them configurable on multiple levels?

I primarily had the reliability issue in mind, but as I am about to publish a draft on how to compose multipath aware protocol stacks, I fear almost all transport features can be implemented at almost all levels… 

> It’s not a contradiction - CONNECT just creates a context, e.g. for configuration transport features (see draft-ietf-taps-transports-usage-udp ). In the minset, a flow can also be a stream of an SC…

Fine - I just know too many people that scream when mentioning UDP and connect together ;-)

>       protocol and the port number used by the transport protocol.

Ok - thanks for clarifying - so no name resolution and endpoint selection in the minimal mindset?

AVE!

---

From: Michael Welzl <[email-masked]>
Date: Tue, 27 Jun 2017 13:21:57 +0200

Hi,

> The question is whether this discussion should go into this or another draft.

But it’s a “minimum set”, so it really *is* okay to go beyond, as long as people are aware about the pro’s and con’s. Anyway, maybe there’s an alternative solution.
My suggestion would be: for any functionality that we’re really missing and that would create a protocol dependency, can we try to raise the abstraction level just enough to avoid the TAPS system coming back and saying “sorry, I can’t” ?

E.g.: “Pick interfaces X and Y” is something that not every protocol can do. Since it relates to system-wide or network-related information (isn’t really application-specific), minset says this could be automatized.
However, giving information about the app behavior like you propose in the socketintents draft can clearly help a TAPS system make the best decision about the interface choice, and it’s only advisory information - if a TAPS system just ignores it, e.g. because MPTCP isn’t available, nothing bad will happen.

> The latter is a good candidate for abstract terms and automation,

… indeed.

> but there might also be use cases for which a more concrete, protocol independent API to bind data to certain paths is needed.

… well yes, perhaps… but maybe only advisory, without guaranteeing success? These things take away freedom to automatize; I’d expect developers of TAPS systems to add some such things anyway if they truly want them, but *recommending* them… ?

> For OOB mechanisms, there might be use of some special flags to the send_frame and recv_frame calls that are a) protocol specific, b) cause an error if called on a flow using the wrong protocol and…

So what OOB mechanism are you missing? I’m a bit confused about this bit, you wrote “OOB mechanisms as discussed above” but this discussion featured us agreeing that one particular feature isn’t useful. So… ?

> But finally, I guess it is needed at both levels. In case “unreliable” it is set at "Flow Group” level, all messages will be unreliable, if set at message level, the single message is sent unreliab…

Yes and yes!  As I wrote in my answer to Theresa, that’s clearly a mistake in the minset, and I’ll fix it - thanks for this catch!

> Oh, I never read that from the Post Socket publications. But I guess we should discuss this with Brian how much he has Post Socket to “Legacy” communication in mind.

Well, that post sockets assumes a system on both ends was my understanding after the last meeting (I think this was a side conversation with Tommy, though, not the open TAPS session). Either way, it’s implicitly clear because it just wouldn’t work without a TAPS-system on both ends (or fall back badly, basically saying “you can’t get this here, all you get is a stream” - which is pretty much the same as saying “sorry, only TCP here”, in which case we haven’t really achieved anything in terms of being protocol-independent).
I agree that this should be made clear in the post-sockets draft.

> I primarily had the reliability issue in mind, but as I am about to publish a draft on how to compose multipath aware protocol stacks, I fear almost all transport features can be implemented at alm…

Thanks again for the reliability catch. I’m looking forward to this other draft, I’m interested in what this is. As long as it can be made to work with existing protocols it would seem in scope to me...

> Ok - thanks for clarifying - so no name resolution and endpoint selection in the minimal mindset?

It’s just a set, not really a mindset  :-)  :-)  :-)

Right, no name resolution (and, with it, remote endpoint selection) because it’s not strictly a mechanism of the protocols that we have used as a basis (btw, we do this in NEAT - but it’s not in the minset).
As for local endpoint selection, see https://tools.ietf.org/html/draft-gjessing-taps-minset-05#appendix-A.1.1 <https://tools.ietf.org/html/draft-gjessing-taps-minset-05#appendix-A.1.1> / AVAILABILITY:
listen allows 1 specified local interface with all protocols, and all local interfaces too. Only SCTP allows listening on only a specific subset of interfaces.
It was a decision to remove this filter and say “any” - we could have said “any, or 1 interface only” if this is really useful… again the logic in removing the “1 interface” case was to say that this choice isn’t application-specific.

Cheers,
Michael