> On 6. jun. 2016, at 20.34, Joe Touch <[email protected]> wrote: > > > > 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.
You seem to be saying “whether a protocol is implemented efficiently or inefficiently can affect the protocol choice”. It can - but it doesn’t translate into a necessity to provide something in the API or not. E.g., you could have neither TCP nor SCTP provide something in the style of SO_SNDLOWAT, or both - either way, which protocol is a better choice isn’t affected by the SO_SNDLOWAT functionality. If only one of them implements it, it becomes less efficient to use it if the application makes demands regarding buffer usage, and makes it a less favorable choice. If the TCP receiver doesn’t implement SACK, this may make TCP a less favorable choice too. There are many such implementation details … but I can’t see what a TAPS RFC should state in order to limit these problems or make things play out better. But now I’m confused :-( I’m thinking of Nagle… you need to offer it in the API or you can’t use it. Why wouldn’t SO_SNDLOWAT be in the same category? So maybe I’m just wrong. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
