Subject: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

From: [email-masked]
Date: Tue, 26 May 2015 05:41:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Services Working Group of the IETF.

        Title           : Services provided by IETF transport protocols and congestion control mechanisms
        Authors         : Godred Fairhurst
                          Brian Trammell
                          Mirja Kuehlewind
	Filename        : draft-ietf-taps-transports-04.txt
	Pages           : 35
	Date            : 2015-05-26

Abstract:
   This document describes services provided by existing IETF protocols
   and congestion control mechanisms.  It is designed to help
   application and network stack programmers and to inform the work of
   the IETF TAPS Working Group.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-transports/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-taps-transports-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-04

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian Trammell <[email-masked]>
Date: Tue, 26 May 2015 15:25:37 +0200

Greetings, all,

We've submitted revision -04 of taps-transports, which includes:

(1) a new section on HTTP as a pseudotransport over TCP (thanks, Dragana Damjanovic!)

(2) a new section on NORM (thanks, Brian Adamson!)

(3) frontmatter in Section 4 normalizing and categorizing the transport protocol components; please review this and suggest necessary or useful changes for using this as background for selecting taps features.

Next up is completing the outstanding sections on transports and transport-like things, of which we have four:

3.2 MP-TCP
3.7 RTP
3.9 TLS/DTLS pseudotransport
3.11 WebSockets

We hope to get an -05 with text for these out in the next couple of weeks, and will follow up with contributors for each of these sections shortly.

Thanks, cheers,

Brian (for the editors of taps-transports)

> On 26 May 2015, at 14:41, [email-masked] wrote:
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Tue, 26 May 2015 15:36:16 -0700

Hi, Brian (et al.),

On 5/26/2015 6:25 AM, Brian Trammell wrote:
...
> (3) frontmatter in Section 4 normalizing and categorizing the
> transport protocol components; please review this and suggest necessary
> or useful changes for using this as background for selecting taps features.

I like the definitions but IMO the protocol descriptions don't follow
the definitions.

I.e., I agree that a transport protocol service (TPS) is a feature or
capability made available to the app, and that a transport protocol
component (TPC) is an implementation of such a feature.

I realize I sound like a broken record, but the descriptions of the
protocols herein still does not match the definition of TPS or TPC.

E.g., for TCP, none of the following is exposed to the user:
	- segmentation
	- flow control
	- congestion control
	- error detection
At best, the effects of the above are exposed to the user in very
indirect fashion, certainly not as a "service" that can be used.

In addition, TCP provides all of the following services (the latter two
depending on being supported), which are not listed:
	- PUSH
	- URG
	- authentication (via TCP-AO or legacy TCP MD5)
	- control over user timeout (UTO option)

This continues to be a pervasive issue in this doc, i.e., not just for
this protocol.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 27 May 2015 15:02:43 +0200

Hi Joe,

I agree. This is a working document and we are still in the phase of collecting data while the next step is to discuss which things that are currently listed must/should be listed or not and also which of the things must/should be exposed to the app.

However, I think we are on the write track for the TSC because these are thing that are implemented independent of the question if these things should be exposed to the app or not. However, features in contrast should really only be the things that should be exposed. The list in section 4 currently copies everything from above and we need to have the discuss now what should stay there and what not. 

Mirja

> Am 27.05.2015 um 00:36 schrieb Joe Touch <[email-masked]>:
> 
> Hi, Brian (et al.),
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 May 2015 10:20:09 -0700

On 5/27/2015 6:02 AM, Mirja Kühlewind wrote:
> Hi Joe,
> 
> I agree. This is a working document and we are still in the phase of
> collecting data while the next step is to discuss which things that are
> currently listed must/should be listed or not and also which of the
> things must/should be exposed to the app.

To be clear, can you clarify the focus?:

	- what IS/IS NOT (i.e., current requirements)

	- what WILL BE/WILL NOT BE (i.e., future goals)

AFAICT, this is about IS/IS NOT. With that in mind, it should not be
necessary to "collect data" and then decide later what is exposed or not.

> However, I think we are on the write track for the TSC because these
> are thing that are implemented independent of the question if these
> things should be exposed to the app or not.

There seems to be ample confusion about:

- upper layer interface (abstract "API"): services to the user

- lower layer interface: services needed from the next protocol layer

- the protocol itself (as an abstract specification: i.e., the finite
state machine rules that relate commands and responses to the ULI, calls
and returns to the LLI, and internal state and events (e.g., timers)

- the *implementation* of any of the above, e.g.:
	- Unix sockets API
	- interface to IPv4
	- Differences that include Reno vs. Cubic..., MTU algs, etc.

> However, features in
> contrast should really only be the things that should be exposed.

IMO, implementation issues should be fully out of scope.

> The
> list in section 4 currently copies everything from above and we need to
> have the discuss now what should stay there and what not.

Frankly, RFC 793 specified exactly what is needed here (it may need to
be augmented with options and later extensions), but that needs to be a
*starting point* for these discussions.

And the current doc doesn't come close to what's in 793.

If we're not starting there, there's little point in starting IMO.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 May 2015 10:49:44 +0200

Hi Joe,

see below...

> Am 27.05.2015 um 19:20 schrieb Joe Touch <[email-masked]>:
> 
> 

It’s about IS/IS NOT. However, currently there is very little (explicitly) exposed to the app.

So the question is actually what should be exposed from the transport service components that are currently implemented in the then different existing transport protocols.

> IMO, implementation issues should be fully out of scope.

It’s not about implementation issues but it’s not always absolutely clear which level of detail must be exposed to the app. Is it enough to only have an interface where you can choose to use congestion control or not, or do you need to choose between delay-based and lost-based congestion control, or foreground and background congestion control, or one specify algorithm, or just specify one specify detail of the algorithm e.g. don’t increase fast than one packet per RTT…? 

So the approach for the current document is to summarize what’s already there. We had some discussions about the level of detail of this document, and I believe we currently have a good compromise where we give some implementation details but also try to not make this document 
unnecessary long.

> If we're not starting there, there's little point in starting IMO.

793 is the starting point. However this doc is not only on TCP. If you think that there important points missing, please propose new text or changes to the current text!

Mirja

---

From: Brian Trammell <[email-masked]>
Date: Thu, 28 May 2015 11:08:56 +0200

hi Mirja, Joe,

two more points inline...

> On 28 May 2015, at 10:49, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Joe,
> 
> see below...
> 
> 

I disagree that implementation- (and indeed, deployment-) level concerns are out of scope here. It's implementation level concerns which have made it necessary to do something like TAPS in the first place. In a world without middlebox impairment you don't need any path condition measurement or negotiation at all, and "transport flexibility" would simply be a matter of sticking libraries on top of TCP and/or SCTP options.

> It’s not about implementation issues but it’s not always absolutely clear which level of detail must be exposed to the app. Is it enough to only have an interface where you can choose to use conges…

There's a second issue here, as well, and it's kind of hiding behind the current structure of the document and the terminology.

Right now, which transport protocol to use is either an explicit choice of the application developer (by selecting an API / library and set of configuration parameters which always map to a single wire protocol) or an implicit one (e.g. by selecting a library or higher-layer protocol on which to develop the application which only supports a single transport protocol).

These protocols have positive properties (which we've called components) and negative properties (that is, use of this protocol excludes some other thing you might want to have). Stupid example: fully reliable single-streaming implies head-of-line blocking. Here the positive and negative properties are intrinsically linked. Less stupid example: assume you want reliable transport of messages but don't care at all about the order in which they arrive (e.g. because you're doing bulk object synchronization as with NORM). In this case reliability would be a positive property of TCP, and head-of-line blocking is a negative property, the positive counterpart of which (stream orientation) you don't even want. In this case, it is the choice of components pulled together into a single protocol at protocol design time which sets up the conflict.

I'm not quite sure how to capture this, or indeed whether this document is where it should be captured, but it is very important for any approach to TAPS which will use off-the-shelf protocols.

Cheers,

Brian

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Thu, 28 May 2015 16:18:33 +0200

HI,

I gave this comment also to version 03, but I will then repeat it here
again :-):

I do think that it is overkill to say that TCP implements the following
Transport Protocol Components:

   o ordered delivery for each byte stream

   o  stream-oriented delivery in a single stream

Given that one TCP connection is able to serve one and only one byte
stream,
I think that it would suffice to give one of these statements. Preferably
the latter one.

BR, Karen

>-----Original Message-----
>From: Taps [mailto:[email-masked]] On Behalf Of Brian Trammell
>Sent: Tuesday, May 26, 2015 3:26 PM
>To: taps WG
>Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt
>
>Greetings, all,
>
>(3) frontmatter in Section 4 normalizing and categorizing the transport
>protocol components; please review this and suggest necessary or useful
>changes for using this as background for selecting taps features.
>
>Next up is completing the outstanding sections on transports and
transport-
>like things, of which we have four:
>
>3.2 MP-TCP
>3.7 RTP
>We hope to get an -05 with text for these out in the next couple of
weeks,
>and will follow up with contributors for each of these sections shortly.
>
>Thanks, cheers,
>
>> This draft is a work item of the Transport Services Working Group of
the
>IETF.
>>
>>        Title           : Services provided by IETF transport protocols
and congestion
>control mechanisms
>> 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.

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2015 10:35:06 -0700

> It’s about IS/IS NOT. However, currently there is very little (explicitly) exposed to the app.

That's contradictory.

What IS/IS NOT exposed as per the specs is easy to determine.

Anything not exposed is either not part of a spec or an incomplete
implementation. Other stuff - like congestion control alg - is
absolutely NOT part of any current TCP spec to expose to the API.

> So the question is actually what should be exposed from the
> transport service components that are currently implemented in the then different
> existing transport protocols.

That's WILL BE, and a completely different issue IMO. If we don't
clearly document the current requirements, it's very difficult to move
forward with deciding how to extend that API.

> It’s not about implementation issues but it’s not always absolutely
> clear which level of detail must be exposed to the app.

It's absolutely clear in RFC 793 at least.

> Is it enough to
> only have an interface where you can choose to use congestion control or
> not,

That's not part of any current spec, so you're back to "tomorrowland"
thinking.

> or do you need to choose between delay-based and lost-based
> congestion control, or foreground and background congestion control, or
> one specify algorithm, or just specify one specify detail of the
> algorithm e.g. don’t increase fast than one packet per RTT…?

Potentially useful, but that's diving very deep into HOW TCP operates,
rather than user-level issues.

This is revisiting the old QOS debate: do you open the entire set of QOS
parameters to the user, or merely provide the user with a set of
user-visible goals and allow the protocol to decide how best to support
them? In QOS, this ended up picking a very few types of service classes.
The same goal might be useful here.

But, again, that's a goal for the future. It's difficult to get there if
there's no clear indication of the current APIs.

> So the approach for the current document is to summarize what’s
> already there.

The doc needs to differentiate between "already required per
specification" and "available in some implementations". The former sets
the baseline. The latter is fodder for discussion of how to standardize
API extensions.

> We had some discussions about the level of detail of this
> document, and I believe we currently have a good compromise where we
> give some implementation details but also try to not make this document
> unnecessary long.

IMO, the problem is that there's no clear distinction between what's
currently required vs. available in some instances.

> 793 is the starting point. However this doc is not only on TCP.

I noted that I was listing the issues with 793 as an example. There are
similar issues with the other transports.

> If
> you think that there important points missing, please propose new text or
> changes to the current text!

I did 6 months and 3 versions ago:
http://www.ietf.org/mail-archive/web/taps/current/msg00402.html

I'll check back in another 6 and see if they're fixed then.

Joe

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 28 May 2015 20:05:14 +0200

Hi Joe,

here is where the confusion comes from: this doc is not about APIs, it’s about transport services, or to say it even more concrete, transport services components and features. We do have a section on interfaces for each protocol but that just an add-on which might or might not be useful to have in this document, but the core of the document is to describe the components that are currently implemented independent of the current provided (app-layer) interface and then add some discuss of which of these components are useful to expose to the app as transport services feature (and which level of detail/degree of decision freedom for each feature).

I know there have been many tries to do this. And I personally think we will not be able to get this right. However, I know that we can do better than what we have right now because that’s clearly broken.

Mirja

> Am 28.05.2015 um 19:35 schrieb Joe Touch <[email-masked]>:
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 May 2015 11:18:26 -0700

On 5/28/2015 11:05 AM, Mirja Kühlewind wrote:
> Hi Joe,
> 
> here is where the confusion comes from: this doc is not about APIs,
> it’s about transport services, or to say it even more concrete,
> transport services components and features.

Such services are either inherent to the transport (e.g., in-order,
reliable delivery) or exposed as a control to the user (by the API).

I.e., APIs are necessary but not sufficient to describe transport services.

> We do have a section on
> interfaces for each protocol but that just an add-on which might or
> might not be useful to have in this document, but the core of the
> document is to describe the components that are currently implemented
> independent of the current provided (app-layer) interface and then add
> some discuss of which of these components are useful to expose to the
> app as transport services feature (and which level of detail/degree of
> decision freedom for each feature).

But then isn't it critical to also know what's already exposed, e.g., in
the existing API?

Joe

---

From: Michael Welzl <[email-masked]>
Date: Thu, 28 May 2015 21:33:43 +0200

> On 28. mai 2015, at 20.18, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Agreed. Things that are in the APIs are what the document calls "transport service features", whereas what you here call "inherent services" is what the document calls "transport protocol components".

I think it's a bit unfortunate that the API descriptions look very different in style from the list of components. Maybe a line could be drawn between:

"transport service features"  (components that are exposed to the application)
... and here come all the things found in today's (not tomorrow's!) APIs, as defined by the specs alone, not implementations
and "transport protocol components"  ... which is all the rest. I'm thinking of just a way of splitting the component lists, just to say "the following ones are exposed in the API today".

> But then isn't it critical to also know what's already exposed, e.g., in

I think so - and the document tries to say that, by describing APIs. Doing it like I propose above could add clarity.

Cheers,
Michael

---

From: Olivier Mehani <[email-masked]>
Date: Fri, 29 May 2015 18:05:15 +1000

Hi all,

On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote:
> Agreed. Things that are in the APIs are what the document calls
> "transport service features", whereas what you here call "inherent
> services" is what the document calls "transport protocol components".

I am not sure I have the same understanding of what features are. More
than what is exposed through the API (which indeed is very little in the
majority of the cases), I think features is what the application
implicitly expects when selecting a specific transport.

I agree more about the components. The application however has no idea
about the components. This is internal stuff within each protocol to
provide the features (e.g., retransmission for reliability), or to be
nice to the network (e.g., congestion control). I don't think the
applications would care much for the latter (or maybe as a hindrance
which limits how much of the capacity it can grab).

At the moment, looking at the draft, I think that most “Transport
Protocol Components” sections actually conflate features and components,
and probably list more of the former than the latter. I don't think this
is quite in line with the terminology:

	Transport Service Feature: : a specific end-to-end feature that
	a transport service provides to its clients. Examples include
	confidentiality, reliable delivery, ordered delivery,
	message-versus-stream orientation, etc.

	Transport Protocol Component: : an implementation of a transport
	service feature within a protocol.

For example for TCP, I would say that the following are features (that the application wants)
- reliable delivery
- ordered delivery for each byte stream
- stream-oriented delivery in a single stream
- unicast
- data bundling (Nagle's algorithm)
- port multiplexing
while these are components (that the application doesn't see)
- connection setup with feature negotiation and application-to-port mapping
- error detection (checksum)
- segmentation
- flow control
- congestion control

> "transport service features"  (components that are exposed to the
> application) ... and here come all the things found in today's (not
> tomorrow's!) APIs, as defined by the specs alone, not implementations
> and "transport protocol components"  ... which is all the rest. I'm
> thinking of just a way of splitting the component lists, just to say
> "the following ones are exposed in the API today".

I think this makes sense. That said, beyond just the specs, I think it
would be useful to consider what current implementations provide too, as
this may offer a slightly different set of features which is,
nonetheless, what developers of real applications are dealing with.

-- 
Olivier Mehani <[email-masked]>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 29 May 2015 10:27:46 +0200

Hi Oliver,

I mostly agree with your understand, only minor points below.

> Am 29.05.2015 um 10:05 schrieb Olivier Mehani <[email-masked]>:
> 
> Hi all,
> 

Yes and no. So what you describe is the current state. A transport service is a set of transport services features and today you can select those features only implicitly by selection the transport protocol itself.

However, I think that it is worth to provide an interface to configure each feature explicitly. Not completely sure yet that it is true. But for me that’s one of the goals of this working group to figure out if this statement is true.

> - error detection (checksum)

I also see this very slightly different. Features and components are for my understanding nothing exclusive. Each feature also has a corresponding component (but not the other way around). However, while the feature is ‚reliable delivery‘ (because that all the app cares about), the component might be more specific like "reliable delivery using accumulated ACKs and retransmissions’ as TCP does.

The more important point is, that the current lists in the doc need work! Maybe some of the point you’ve listed above as features must be phrased more detailed to describe/list the actually component and then we need to decide which components actually also provide a feature (that should be exposed) and on which level this correlates to a feature. So the split you proposed above is a good starting point for this.

> nonetheless, what developers of real applications are dealing with.

You mean it term of APIs or component? Collecting information of components are are currently implemented/used is the purpose of this doc. Collecting information about API/config interfaces of what is implemented/used today is also useful but a rat-hole… therefore we try cover this aspect briefly in this doc but do not aim for completeness here.

Mirja

---

From: Michael Welzl <[email-masked]>
Date: Fri, 29 May 2015 11:30:59 +0200

> On 29 May 2015, at 10:27, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi Oliver,
> 

I just want to give a +1 on the rat-hole. IF we care about what protocols currently offer to apps via their API, we should only worry about what the specs say.  (which also has its issues because I'm not sure all specs do say enough)

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Fri, 29 May 2015 10:32:41 -0700

First, I think this discussion would benefit from a clarification of
what "API" means, or at least to stop using that term in isolation.

There are three distinct concepts:

	A- abstract protocol "upper layer interface"	
		e.g., OPEN, CLOSE, ABORT, as per RFC 793

	B- programmer API
		e.g., Linux C/C++ TCP socket interface

	C- instance of a programmer API
		e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface

IMO, this document MUST discuss A, and can be address potential
extensions to A based on examining variants of B and C.

There are also the protocol features, which are the properties of the
protocol that:
	- can be explicitly configured and monitored
		these are *exactly* A, B, and/or C above

	- can be implicitly detected
		some are based on the definition of the protocol,
		such as reliable, byte sequence delivery

		some are an artifact of the implementation,
		such as specific delays due to burst losses

However, *none* of this is a rat-hole IF TAPS is intended to explain the
service interface to the user. IMO, B and C above should be secondary
considerations after A is clearly documented, but this draft is a long
way from that.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Sat, 30 May 2015 14:24:41 +0200

> On 29. mai 2015, at 19.32, Joe Touch <[email-masked]> wrote:
> 

I agree: A should be there, and it should probably the primary focus, as starting with a list of A would add a lot of clarity to the document and the discussion of it.

Some text on protocol internals, explaing what a protocol does even though these things may not be exposed to an application, can be valuable even if only to know which protocol to choose. So I'm not suggesting removing everything but I'd agree that the focus of the document should shift towards a list of A.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Sat, 30 May 2015 14:31:22 +0200

> On 28. mai 2015, at 11.08, Brian Trammell <[email-masked]> wrote:
> 
> hi Mirja, Joe,
> 

This sounds like you were talking cross purposes. My interpretation here is that Joe is saying (as in his other email) that "concept A" in his other email:
http://www.ietf.org/mail-archive/web/taps/current/msg00490.html
should be in scope of the discussion, but B and C should not. I agree with that and your answer doesn't say you don't.

How to implement / deploy something are concerns that should be in scope of TAPS (they clearly are as per item 3 in its charter), but not necessarily in scope of this first document.

> I'm not quite sure how to capture this, or indeed whether this document is where it should be captured, but it is very important for any approach to TAPS which will use off-the-shelf protocols.

I do believe, based on our own prior work, that you'll find surprisingly few such conflicts. I agree that documenting them will be important, but it seems obvious to me that this should be done as a second step, after creating a list of what all the protocols offer to applications. Probably in the same document, but let's first get that list right.

Cheers,
Michael

---

From: Olivier Mehani <[email-masked]>
Date: Mon, 1 Jun 2015 10:17:53 +1000

Hey Mirja,

On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja Kühlewind wrote:
> > I am not sure I have the same understanding of what features are.
> > More than what is exposed through the API (which indeed is very
> > little in the majority of the cases), I think features is what the
> > application implicitly expects when selecting a specific transport.
> Yes and no. So what you describe is the current state. A transport
> service is a set of transport services features and today you can
> select those features only implicitly by selection the transport
> protocol itself.
> However, I think that it is worth to provide an interface to configure
> each feature explicitly. Not completely sure yet that it is true. But
> for me that’s one of the goals of this working group to figure out if
> this statement is true.

Yes, that's how I understand it too. Nonetheless, we need to start with
what we have: groups of features that we need to identify and separate.

> > is quite in line with the terminology:
[...]
> I also see this very slightly different. Features and components are
> for my understanding nothing exclusive. Each feature also has a
> corresponding component (but not the other way around). However, while
> the feature is ‚reliable delivery‘ (because that all the app cares
> about), the component might be more specific like "reliable delivery
> using accumulated ACKs and retransmissions’ as TCP does.

Yes, I completely agree. But I think the difference you higlight is
important: each feature has one (or more, I'd say) corresponding
components, while components might not necessarily result in an
application-visible feature. 

> The more important point is, that the current lists in the doc need
> work! Maybe some of the point you’ve listed above as features must be
> phrased more detailed to describe/list the actually component and then
> we need to decide which components actually also provide a feature
> (that should be exposed) and on which level this correlates to a
> feature. So the split you proposed above is a good starting point for
> this.

I'm glad to read it (:

> >> tomorrow's!) APIs, as defined by the specs alone, not
> >> implementations and "transport protocol components"  ... which is
> >> all the rest. I'm thinking of just a way of splitting the component
> >> lists, just to say "the following ones are exposed in the API
> >> today".
> > I think this makes sense. That said, beyond just the specs, I think
> > it would be useful to consider what current implementations provide
> > too, as this may offer a slightly different set of features which
> > is, nonetheless, what developers of real applications are dealing
> > with.
> You mean it term of APIs or component? Collecting information of
> components are are currently implemented/used is the purpose of this
> doc. Collecting information about API/config interfaces of what is
> implemented/used today is also useful but a rat-hole… therefore we try
> cover this aspect briefly in this doc but do not aim for completeness
> here.

Yes, this is likely for a later document. However, I think we should
make sure that some transport API have not implemented some
non-standardised behaviours that a non-negligible number of applications
use. I am not sure it's the case, but if it is so, we probably want to
take that onboard at some point too.