Subject: [Taps] TAPS: Getting things named correctly... what is a "transport service"

From: [email-masked]
Date: Thu, 6 Nov 2014 10:55:20 -0000

So...

One of the things I have been trying to understand over the last couple of
weeks is what entities we have to name in TAPS, and how we give the
entities names that seem to be understood by our community and preferably
are common with other uses in the IETF.

I came across one term that appears to be defined differently in the
charter discussions, to how I would normally understand this. This email
tries to explain this, if you think the same as me, please speak-up and
say this, if you think another definition is better, please say why.

I think the group just needs to decide at this stage, so that all actual
RFCs that are made will be consistent.

---
1) Transport Service

I see a "Transport Service" as an end-to-end service that has
traditionally been mapped by transport people  down to a "port/socket"
(perhaps the "S" part of tsv).

This appears consistent with other uses, I have come across. However, a
service is usually composed of a number of "components" - I seem to recall
these be called "service elements" in OSI. Examples are: reliability,
multicast, confirmed delivery, congestion control, integrity, minimal
latency, etc. (we could, and probably should make a list).

Application
   |
Transport Service(s)
   |                  |
Service          Service
Component   Component(s)

Hence, I see a service as offered via an API to an App or upper-layer
protocol. I see a service as having multiple components. This is not
necessarily the usage in the final charter fro TAPS!!

---

2) When the charter says; "Four examples of Transport Services are reliable
delivery, ordered delivery of data, content privacy to in-path
devices, and minimal latency."

- I think these could indeed be transport services, but I'd actually now
suggest they could be better described as components/elements of a
transport service. In my thinking, one could always build an entire
service that was oriented at "minimal latency" - but equally one could
conceive of this as a transport service component that could be combined
with security, ordering, etc. (using the language above).

---

3) Transport Protocols

Transport protocols are not a service, because many transport protocols
can provide multiple services (again my own terminology). Indeed a single
transport can negotiate to support multiple "features". A "feature"
represents a choice of protocol mechanisms/parameters to instantiate a
service (or one component of a service, e.g. use of ECN, optional
integrity
checks, etc). This term has been sued before, one of the older uses could
be FTP feature negotiation. DCCP formally included "features" in its
protocol design.

Transport protocol
   |                  |
Feature          Feature(s)
   |
Protocol
mechanism(s)

---

For anyone in fear this is endless, it is NOT going to be. Mirja will
present slides to ask for confirmation of the hierarchy terms at the
meeting next week, and after a <shot> discussion we plan to very quickly
and publish a new revised ID with the WG-"approved" terms and use these
hence-forth.

Gorry

---

From: Mirja Kühlewind <[email-masked]>
Date: Sat, 8 Nov 2014 14:03:32 -1000

Hi all,

one more proposal that in not inline with the charter definition but therefore more similar to Gorry’s proposal. Basically we could even avoid to use the term ‚transport service‘ as a stand-alone term and always use ‚transport service <something>‘ instead to make the meaning more explicit (see below). Further in addition to Gorry’s definition below I still think we also need to distinguish something that actually provides a certain implementation based on a concrete protocol/stack etc.

Therefore this proposal:

transport service component: e.g reliability

transport service composition: a set of components (without any association to a certain framing protocol).

transport protocol: an implementation (using a specific framing/header format) providing different transport service service compositions

transport protocol feature: an implementation of one certain transport service component e.g. reliability using ACKs (instead of NACKs)

transport service instance: one implementation of one service composition utilizing one or multiple protocols with a selected set of features (and a certain parameterization), e.g. a protocol stack (RTP over UDP) or even something that switches between two protocols depending on the network conditions

Any comments?

Mirja

> Am 06.11.2014 um 00:55 schrieb [email-masked]:
> 
> 
> So...
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps