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. 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. > >> 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. Is it enough to only have an interface where you can choose to use congestion control or not, 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…? So the approach for the current document is to summarize what’s already there. 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. > >> 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. If you think that there important points missing, please propose new text or changes to the current text! Mirja > > Joe > > >> Mirja >> >> >>> Am 27.05.2015 um 00:36 schrieb Joe Touch <to...@isi.edu>: >>> >>> Hi, Brian (et al.), >>> >>> On 5/26/2015 6:25 AM, Brian Trammell wrote: >>> ... >>>> (3) frontmatter in Section 4 normalizing and categorizing the >>>> transport protocol components; please review this and suggest necessary >>>> or useful changes for using this as background for selecting taps features. >>> >>> I like the definitions but IMO the protocol descriptions don't follow >>> the definitions. >>> >>> I.e., I agree that a transport protocol service (TPS) is a feature or >>> capability made available to the app, and that a transport protocol >>> component (TPC) is an implementation of such a feature. >>> >>> I realize I sound like a broken record, but the descriptions of the >>> protocols herein still does not match the definition of TPS or TPC. >>> >>> E.g., for TCP, none of the following is exposed to the user: >>> - segmentation >>> - flow control >>> - congestion control >>> - error detection >>> At best, the effects of the above are exposed to the user in very >>> indirect fashion, certainly not as a "service" that can be used. >>> >>> In addition, TCP provides all of the following services (the latter two >>> depending on being supported), which are not listed: >>> - PUSH >>> - URG >>> - authentication (via TCP-AO or legacy TCP MD5) >>> - control over user timeout (UTO option) >>> >>> This continues to be a pervasive issue in this doc, i.e., not just for >>> this protocol. >>> >>> Joe >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
