> On 28. mai 2015, at 11.08, Brian Trammell <i...@trammell.ch> wrote: > > hi Mirja, Joe, > > two more points inline... > >> On 28 May 2015, at 10:49, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> >> 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. >> >> 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.
This sounds like you were talking cross purposes. My interpretation here is that Joe is saying (as in his other email) that "concept A" in his other email: http://www.ietf.org/mail-archive/web/taps/current/msg00490.html should be in scope of the discussion, but B and C should not. I agree with that and your answer doesn't say you don't. How to implement / deploy something are concerns that should be in scope of TAPS (they clearly are as per item 3 in its charter), but not necessarily in scope of this first document. >> 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. I do believe, based on our own prior work, that you'll find surprisingly few such conflicts. I agree that documenting them will be important, but it seems obvious to me that this should be done as a second step, after creating a list of what all the protocols offer to applications. Probably in the same document, but let's first get that list right. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
