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
