Hi Oliver, I mostly agree with your understand, only minor points below.
> Am 29.05.2015 um 10:05 schrieb Olivier Mehani <olivier.meh...@nicta.com.au>: > > 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. 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. > > 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 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. > >> "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. 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 > > -- > 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. _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
