Hey Mirja, On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja Kühlewind wrote: > > 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.
Yes, that's how I understand it too. Nonetheless, we need to start with what we have: groups of features that we need to identify and separate. > > 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: [...] > > > > 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. Yes, I completely agree. But I think the difference you higlight is important: each feature has one (or more, I'd say) corresponding components, while components might not necessarily result in an application-visible feature. > 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. I'm glad to read it (: > >> "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. Yes, this is likely for a later document. However, I think we should make sure that some transport API have not implemented some non-standardised behaviours that a non-negligible number of applications use. I am not sure it's the case, but if it is so, we probably want to take that onboard at some point too. -- 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.
pgpocHjNVV0UF.pgp
Description: PGP signature
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
