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.
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). Mirja > Am 29.05.2015 um 08:56 schrieb Karen Elisabeth Egede Nielsen > <karen.niel...@tieto.com>: > > 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:mich...@ifi.uio.no] >> Sent: Thursday, May 28, 2015 9:39 PM >> To: Karen Elisabeth Egede Nielsen >> Cc: Aaron Falk; taps@ietf.org >> Subject: Re: [Taps] API richness >> >> >>> On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen >> <karen.niel...@tieto.com> 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 > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
