Subject: [Taps] terminology for draft-fairhurst-taps-transports

From: Brian Trammell <[email-masked]>
Date: Tue, 4 Nov 2014 14:14:09 +0100

Greetings, all,

As promised, here's an initial suggestion for terminology in draft-fairhurst-taps-transports, compatible with but elaborating on the minimal terminology in the charter, which would we would propose applies to all TAPS work derived from this document:

Transport Service: 
An end-to-end facility provided by the transport layer that impacts the design, operation, or deployment of the application using it. Example Transport Services include reliable delivery of data, ordered delivery of data, confidentiality of data with respect to in-path devices, or latency guarantees for data transport. 

Transport Service Composition: 
A set of Transport Services taken together to meet the requirements of an application for a given end-to-end interaction. Note that some potential sets of Transport Services  given transport service may preclude the simultaneous use of other transport services for a given end-to-end interaction (e.g. "reliable delivery" and "time-dependent expiry of unacknowledged messages" as per SCTP-PR are mutually exclusive). An example of a Transport Service Composition would be that provided by the BSD SOCK_STREAM socket type: reliable, ordered, non-boundary-perserving, stream-oriented transport, with limited out of band capability. 

Transport Instance: 
A Transport Instance is an arrangement of transport protocols, potentially encapsulated, and configurations thereof that implement a Transport Service Composition. A given Transport Service Composition may be implemented by multiple Instances (e.g., SOCK_STREAM can be implemented atop TCP, SCTP, or SCTP over UDP). 

Application: 
In this and subsequent documents, an Application is defined as an entity that uses the transport layer to interact with a remote Application according to some set of requirements which can be met by Transport Services.

Here I'm pointedly leaving "transport protocol" undefined, mainly so as to sidestep marginally productive conversations about how many transport protools SCTP over DTLS over UDP is. The exact implementation of a Transport Service Composition would appear to be a matter for our third deliverable anyway. :)

It's not perfect but it's a start. Thoughts?

Cheers,

Brian

---

From: Michael Welzl <[email-masked]>
Date: Tue, 4 Nov 2014 14:31:00 +0100

> It's not perfect but it's a start. Thoughts?

We can and will probably debate this to death, but before that happens I'll say: I think this is a very good starting point, thanks!

Cheers,
Michael

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 4 Nov 2014 13:32:01 +0000

If we agree that "transport protocol" is undefined then "Transport Instance" should not use it?

then:
> A Transport Instance is an arrangement of transport protocols, potentially encapsulated, and configurations thereof that implement a Transport Service Composition
Could be 
> A Transport Instance defines an implementation of a Transport Service Composition.
(or something like that?

Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Nov 4, 2014, at 8:14 AM, Brian Trammell <[email-masked]> wrote:
> 
> Greetings, all,
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps