hi Mirja, Joe, two more points inline...
> On 28 May 2015, at 10:49, Mirja Kühlewind <[email protected]> > wrote: > > Hi Joe, > > see below... > > >> Am 27.05.2015 um 19:20 schrieb Joe Touch <[email protected]>: >> >> >> 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. I disagree that implementation- (and indeed, deployment-) level concerns are out of scope here. It's implementation level concerns which have made it necessary to do something like TAPS in the first place. In a world without middlebox impairment you don't need any path condition measurement or negotiation at all, and "transport flexibility" would simply be a matter of sticking libraries on top of TCP and/or SCTP options. > 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…? There's a second issue here, as well, and it's kind of hiding behind the current structure of the document and the terminology. Right now, which transport protocol to use is either an explicit choice of the application developer (by selecting an API / library and set of configuration parameters which always map to a single wire protocol) or an implicit one (e.g. by selecting a library or higher-layer protocol on which to develop the application which only supports a single transport protocol). These protocols have positive properties (which we've called components) and negative properties (that is, use of this protocol excludes some other thing you might want to have). Stupid example: fully reliable single-streaming implies head-of-line blocking. Here the positive and negative properties are intrinsically linked. Less stupid example: assume you want reliable transport of messages but don't care at all about the order in which they arrive (e.g. because you're doing bulk object synchronization as with NORM). In this case reliability would be a positive property of TCP, and head-of-line blocking is a negative property, the positive counterpart of which (stream orientation) you don't even want. In this case, it is the choice of components pulled together into a single protocol at protocol design time which sets up the conflict. I'm not quite sure how to capture this, or indeed whether this document is where it should be captured, but it is very important for any approach to TAPS which will use off-the-shelf protocols. Cheers, Brian > 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 <[email protected]>: >>>> >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
