> On 29 May 2015, at 11:25, Karen Elisabeth Egede Nielsen > <[email protected]> wrote: > > HI Mirja, > > >> -----Original Message----- >> From: Mirja Kühlewind [mailto:[email protected]] >> Sent: Friday, May 29, 2015 10:13 AM >> To: Karen Elisabeth Egede Nielsen >> Cc: Michael Welzl; taps WG >> Subject: Re: [Taps] API richness >> >> Hi Karen, >> >> instead of discussing what applications currently configure, I would rather >> like >> to know why they configure it; what the goal they try to reach and what’s >> the >> problem they try to handle with that. The reason why I’m saying this, is >> because the current configuration possibilities are often very limited and >> something even on the wrong level. To figure out how to do this better, we >> need to understand what the application really wants. >> > [Karen ] Yes I couldn't agree more. > I will also concur that some of the present tuning is done to overcome some > deficiencies in the protocol algorithms, but generally the below reflect > needs of > the applications to have the transport layer service stay within certain > latency limits and to > bail out from using the particular transport service layer (connection) if > these limits are not withheld. > > I agree than one should extrapolate to the right generic features, > to do that one should extrapolate from the existing concrete examples.
Okay, it seems we're all on the same page. My heavy reaction to the email before (and sorry Karen, I had forgotten why you sent it! Indeed that was agreed upon at the last meeting) was because I'm afraid of the logical conclusion: "this is what applications currently configure in current protocols" => "this is what a TAPS API would need to provide". Rather, I think it would be better to focus on *why* applications currently configure the things they do, such that we can then provide something reasonable and meaningful to them. Then again, even that is something we could spend much time on, and possibly in vain: I believe that applications that are configuring all these things nowadays probably wouldn't be "customers" of TAPS anyway. TAPS generally targets programmers of applications who are willing to give up some control, for the possible benefits that come with abstraction. This will always only be a subset of applications. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
