> On 1. jun. 2015, at 03.17, Olivier Mehani <[email protected]> wrote: > > 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.
I'd like to stress "at some point" (if at all). Maybe not even in this particular document? This is exactly the layering problem here - transport protocol designers will have thought through what kind of information should be exposed. App programmers are now facing today's systems that they need to optimize as good as they can. Maybe ad hoc decisions are / were made to allow some protocol tuning that shouldn't really be an application's problem. To me, apps fine tuning protocols in non-standard ways is already one small step in the direction of what TAPS is trying to help against: every application programmer re-doing the job again, developing their own transport protocols inside their app. I think it's important to start with what the protocol designers thought should be exposed and no more, and then we can draw a clean line and say "look, maybe these decisions should be revisited, this and this is constantly being used by applications". Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
