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. >Regarding congestion control, that’ a good example. In most implementation >you can configure the algorithm used in TCP. However, usually people do not >change this configuration because they don’t understand what the benefits >are that a certain algorithm (with a random name) provides. Therefore >actually choose the algorithm seems to be on the wrong level. The interface >should rather configure what service a certain congestion control algorithm >provides e.g. foreground vs. background congestion control. (Not saying >that >this is the right thing to do; just an example what you could do; we need >to >figure out what’s the right thing to do by discussing application need). > [Karen ] Agree. BR, Karen >Mirja > > >> Am 29.05.2015 um 08:56 schrieb Karen Elisabeth Egede Nielsen ><[email protected]>: >> >> HI Michael, >> >> Yes this api richness _may_ be out of scope of Taps. >> I am writing this as information as discussed at the taps wg meeting. >> >> If the Taps api is going to be useful I think that it is relevant to >> put it in context of the needs of applications - >> >> Don't you think so ? >> >> I am not saying that the taps api would need to address the present >> tuning needs described below, but I think that it is relevant to >> understands the present tuning needs, and to understand how taps fits >> into this. >> >> With CC tuning, I meant control which CC algorithm to choose. >> >> BR, Karen >> >>> -----Original Message----- >>> From: Michael Welzl [mailto:[email protected]] >>> Sent: Thursday, May 28, 2015 9:39 PM >>> To: Karen Elisabeth Egede Nielsen >>> Cc: Aaron Falk; [email protected] >>> Subject: Re: [Taps] API richness >>> >>> >>>> On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen >>> <[email protected]> wrote: >>>> >>>> HI, >>>> >>>> As an example of presently relied on API richness, then the >>>> following parameters of TCP/SCTP are parameters that today typically >>>> are tuned by signaling applications on a per connection/association >>>> basis or an a per signaling application basis. Here multiple >>>> signaling applications may share the same TCP/SCTP transport layer >>>> instance (SW >>>> block) but may configure their usage of the protocol (of their TCP >>>> connection/SCTP assoc differently). >>>> In terms of Taps terminology I think this corresponds to a shared " >>>> Transport Service Instance". >>>> >>>> I may note that the parameters even typically are exposed at O&M >>>> level as configurable by the Operators, here even possibly on an >>>> association/connection basis. >>>> >>>> For TCP: >>>> >>>> RTO_MIN, RTO_MAX, MAXRT, SND BUF, RCV BUF, Delay_ack, No_delay, >>> TCP >>>> keep alive settings, >>>> >>>> For SCTP: >>>> >>>> RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, >>> No_delay, >>>> HBI, Association.Max.Retrans, Path.Max.Retrans, >>>> >>>> There are other parameters as well that are tuned on a per TCP >>>> connection/SCTP association basis, but this is in more special cases. >>>> For example TCP (and even SCTP) ABC slow start parameter L, TCP time >>>> wait period. >>>> >>>> The above parameters relates only to the core TCP and SCTP functions >>>> relied on by signaling applications. >>>> Speaking additional features, e.g., ECN, special SCTP features >>>> management opens up for more of course. >>> >>> This strikes me as out of scope of TAPS: why discuss what (some) >> applications >>> today typically tune? >>> >>> >>>> The CC algorithm today is not tuned - default is used - in the >>>> future this should be different, but I think that there is general >>>> agreement that such should indeed be tuned at the TAPS API. >>> >>> Then I think I'm in the "don't agree" camp... >>> >>> Cheers, >>> Michael >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
