> On 29 May 2015, at 10:27, Mirja Kühlewind <[email protected]> > wrote: > > Hi Oliver, > > I mostly agree with your understand, only minor points below. > >> Am 29.05.2015 um 10:05 schrieb Olivier Mehani <[email protected]>: >> >> 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.
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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
