On 6/6/2016 11:20 AM, Michael Welzl wrote: >> On 6. jun. 2016, at 19.15, Joe Touch <[email protected]> wrote: >> >> >> >> On 6/6/2016 1:17 AM, Michael Welzl wrote: >>>> 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. >> Please explain why you think that's true. >> >> AFAICT, it's fundamental to how any protocol interacts with the OS. > Yes it is, but it’s also orthogonal to the choice of protocol - as you said, > it really has nothing to do with TCP. Yes, but configuration of the OS interface isn't orthogonal to that choice.
I.e., constraints of the OS interface may play into the decision of which transport to use, and which transport is chosen may affect the configuration of that OS interface. > Using my typical example again: you can’t use an SCTP mechanism like e.g. > unordered message delivery without knowing that the application wants it, or > else you’ll break the semantics of the application data stream. > It's is a mechanism of SCTP that simply cannot be used unless it’s chosen via > an API. > > Can you say the same about this SO_SNDLOWAT stuff? As far as I’m concerned > such send buffer management is an implementation detail - you could implement > this very well or extremely badly for every protocol The way the OS relays information to the transport IS a protocol - just not one that involves communication on the wire. It significantly affects the way in which the transport operates. > - but even an implementation that gives you almost no choice of what goes on > in the buffer does not prohibit you from using a mechanism that a protocol > provides. Sure, but if you're trying to set TCP to very low latency and use a huge socket buffer, you could easily be creating huge delays and jitter in the interaction between the process scheduling to fill the buffer and the transfer of info into TCP. > It’s a different matter, because the semantics stay unaltered: if you set the > buffer very small with SO_SNDLOWAT, TCP will just fail on you. It’s not going > to lose any packets, it stays reliable. If you could make it lose packets by > changing SO_SNDLOWAT, that would be a different matter I think... It might not affect TCP, but it could affect a protocol that can choose between ARQ and FEC and use ARQ only where the latency budget permits. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
