> 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
