Hi all, On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote: > >> 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. > 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 <olivier.meh...@nicta.com.au>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.
pgp8XLm_b9Hhm.pgp
Description: PGP signature
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
