> On 27 Apr 2016, at 23:25, Joe Touch <[email protected]> wrote: > > > > On 4/27/2016 1:16 AM, Michael Welzl wrote: >> Thinking about Toerless' general point of using more modern APIs made >> me think of the bigger picture again. For example, one cool recent >> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows >> better control of the sender buffer. Not including it in an API >> document "sucks" and it IS nice to include it in a description of an >> API. > > This is an interesting example. It affects how a user-level process > interacts with the protocol implementation inside the OS but has NOTHING > to do with TCP. > > I'm not sure where I would put that. It clearly isn't part of the TCP > API. Nor, e.g., would be the "nice" level of the process that's feeding > data to TCP -- yet both could affect performance between two applications. > > It seems like there's a gap here you could drive a truck through that > needs to be addressed. I'm not sure where, though - i.e., whether this > is part of TAPS or not.
Not part of TAPS I think, because it's not related to automatizing the use of protocols other than TCP or UDP. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
