Hi Joe, 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. We do have a section on interfaces for each protocol but that just an add-on which might or might not be useful to have in this document, but the core of the document is to describe the components that are currently implemented independent of the current provided (app-layer) interface and then add some discuss of which of these components are useful to expose to the app as transport services feature (and which level of detail/degree of decision freedom for each feature).
I know there have been many tries to do this. And I personally think we will not be able to get this right. However, I know that we can do better than what we have right now because that’s clearly broken. Mirja > Am 28.05.2015 um 19:35 schrieb Joe Touch <to...@isi.edu>: > > > > On 5/28/2015 1:49 AM, Mirja Kühlewind wrote: >> Hi Joe, >> >> see below... >> >> >>> Am 27.05.2015 um 19:20 schrieb Joe Touch <to...@isi.edu>: >>> >>> >>> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: >>>> Hi Joe, >>>> >>>> I agree. This is a working document and we are still in the phase of >>>> collecting data while the next step is to discuss which things that are >>>> currently listed must/should be listed or not and also which of the >>>> things must/should be exposed to the app. >>> >>> To be clear, can you clarify the focus?: >>> >>> - what IS/IS NOT (i.e., current requirements) >>> >>> - what WILL BE/WILL NOT BE (i.e., future goals) >>> >>> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >>> necessary to "collect data" and then decide later what is exposed or not. >> >> It’s about IS/IS NOT. However, currently there is very little (explicitly) >> exposed to the app. > > That's contradictory. > > What IS/IS NOT exposed as per the specs is easy to determine. > > Anything not exposed is either not part of a spec or an incomplete > implementation. Other stuff - like congestion control alg - is > absolutely NOT part of any current TCP spec to expose to the API. > >> So the question is actually what should be exposed from the >> transport service components that are currently implemented in the then >> different >> existing transport protocols. > > That's WILL BE, and a completely different issue IMO. If we don't > clearly document the current requirements, it's very difficult to move > forward with deciding how to extend that API. > >>>> However, I think we are on the write track for the TSC because these >>>> are thing that are implemented independent of the question if these >>>> things should be exposed to the app or not. >>> >>> There seems to be ample confusion about: >>> >>> - upper layer interface (abstract "API"): services to the user >>> >>> - lower layer interface: services needed from the next protocol layer >>> >>> - the protocol itself (as an abstract specification: i.e., the finite >>> state machine rules that relate commands and responses to the ULI, calls >>> and returns to the LLI, and internal state and events (e.g., timers) >>> >>> - the *implementation* of any of the above, e.g.: >>> - Unix sockets API >>> - interface to IPv4 >>> - Differences that include Reno vs. Cubic..., MTU algs, etc. >>> >>>> However, features in >>>> contrast should really only be the things that should be exposed. >>> >>> IMO, implementation issues should be fully out of scope. >> >> It’s not about implementation issues but it’s not always absolutely >> clear which level of detail must be exposed to the app. > > It's absolutely clear in RFC 793 at least. > >> Is it enough to >> only have an interface where you can choose to use congestion control or >> not, > > That's not part of any current spec, so you're back to "tomorrowland" > thinking. > >> or do you need to choose between delay-based and lost-based >> congestion control, or foreground and background congestion control, or >> one specify algorithm, or just specify one specify detail of the >> algorithm e.g. don’t increase fast than one packet per RTT…? > > Potentially useful, but that's diving very deep into HOW TCP operates, > rather than user-level issues. > > This is revisiting the old QOS debate: do you open the entire set of QOS > parameters to the user, or merely provide the user with a set of > user-visible goals and allow the protocol to decide how best to support > them? In QOS, this ended up picking a very few types of service classes. > The same goal might be useful here. > > But, again, that's a goal for the future. It's difficult to get there if > there's no clear indication of the current APIs. > >> So the approach for the current document is to summarize what’s >> already there. > > The doc needs to differentiate between "already required per > specification" and "available in some implementations". The former sets > the baseline. The latter is fodder for discussion of how to standardize > API extensions. > >> We had some discussions about the level of detail of this >> document, and I believe we currently have a good compromise where we >> give some implementation details but also try to not make this document >> unnecessary long. > > IMO, the problem is that there's no clear distinction between what's > currently required vs. available in some instances. > >>>> The >>>> list in section 4 currently copies everything from above and we need to >>>> have the discuss now what should stay there and what not. >>> >>> Frankly, RFC 793 specified exactly what is needed here (it may need to >>> be augmented with options and later extensions), but that needs to be a >>> *starting point* for these discussions. >>> >>> And the current doc doesn't come close to what's in 793. >>> >>> If we're not starting there, there's little point in starting IMO. >> >> 793 is the starting point. However this doc is not only on TCP. > > I noted that I was listing the issues with 793 as an example. There are > similar issues with the other transports. > >> If >> you think that there important points missing, please propose new text or >> changes to the current text! > > I did 6 months and 3 versions ago: > http://www.ietf.org/mail-archive/web/taps/current/msg00402.html > > I'll check back in another 6 and see if they're fixed then. > > Joe _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
