New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semantics of "low latency" #90

Closed
mwelzl opened this Issue Feb 25, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@mwelzl
Contributor

mwelzl commented Feb 25, 2018

In issue #65, we discussed that "Immediate Acknowledgement" (from SCTP) is a bit too protocol-specific and could maybe be called "low latency", allowing the stack to automatically turn this on "under the hood".

I think the only use case for this is when an application executes tight control over the send buffer, and wants to be able to change what it hands over to the transport system at the last minute - then, it is probably good to know ASAP when a particular Message has really arrived at the receiver.
This would be an application that requires low latency.

The API currently has another send parameter called "immediate". This would turn off the Nagle algorithm, for example - it represents a wish to send stuff fast, possibly at the cost of wasting capacity (more header overhead, or other things).

I don't think that an application that needs "immediate" would always also need "immediate acknowledgement" or vice versa - these seem to be two different things.

Should we have two boolean send parameters for these two types of requests?
"Prefer low latency" (to trade against capacity) and "ACK ASAP" ?

@mwelzl mwelzl added the API label Feb 25, 2018

@gorryfair

This comment has been minimized.

gorryfair commented Feb 26, 2018

I'd suggest that when you say "the only use case for this is", you're starying to make me think this is a very specific application use. The immediate stuff in SCTP was a very specific use. I'm quite OK with believing other use-cases exist, what I'd question is whether this specific feature needs to be in a generic API?

@mwelzl

This comment has been minimized.

Contributor

mwelzl commented Feb 26, 2018

In SCTP, there were SCTP-internal reasons AND there was the app reason: https://tools.ietf.org/html/rfc7053#section-4.1 I now wonder whether this is something that COULD somehow be handled internally in the transport system, or if we need to expose a flag to enable this kind of thing. I'll follow up with emails.

@mwelzl

This comment has been minimized.

Contributor

mwelzl commented Feb 26, 2018

TL;DR: I thought more about this. I started to write an email, and writing made me think deeper and understand better. I conclude that, whether to get ACKs back immediately or not is also just a matter of trading latency against overhead, and indeed one "low latency" bit is enough. Actually we don't need an extra bit because this is already covered by the message property "Immediate" (which is about, e.g., disabling Nagle - but the point is that these things go together: lower latency at the cost of overhead).

Below, I describe the background for my conclusion. It would be good if someone could check it for potential logical errors.

Tommy once described Apple's model of buffer control to me as follows:


I consider TCP_NOTSENT_LOWAT to be an implementation detail of the sockets API, and not really the right model here.
The backpressure we have is based on the asynchronous callback. Nothing is blocking.
If the application wants to slow down the generation of its content based on back pressure from the stack, it should wait to generate another send based on the callback to the previous send being fired. However, you may enqueue multiple sends back to back, since the data may already be generated. This gives all of the capabilities of back pressure, without blocking, or forcing it.


I think this approach is just right. What this doesn't discuss, however, is how to configure the low water mark of TCP - and I think an efficient implementation of a transport system would statically configure it as low as possible, such that most buffering happens inside the transport system, not in TCP, and the application does get maximum control over it via the Sent callbacks.

Now, turn to SCTP as a model. ACK-immediately just means that, in case of reliable transfer, SCTP can delete stuff from its own retransmit buffer faster (In SCTP, and only SCTP, this directly concerns the application because SCTP's "sender dry event" concerns both unsent and unacknowledged data). So if the transport system would want to keep SCTP's send buffer small, it could turn on "ACK-immediately", at the cost of overhead (more ACKs on the backward path), but because "sender dry" isn't what we should expose to the application (BECAUSE it mixes the unsent and unack'ed data buffer, and because it fires when it's too late anyway - the buffer really is at 0), we also shouldn't expose control over ACK-immediately.

@britram

This comment has been minimized.

Contributor

britram commented Apr 16, 2018

This is on the list to resolve for ietf-00 (which may or may not be intentional). I think the action here is to replace the Immediate Acknowledg(e)ment send property with an Low Latency send property with more or less the same semantics as the Immediate send property (which I thought was still there, but appears to have been removed...? oops, someone!).

An open question is whether or not we also need a protocol selection property for low latency, which (1) verifies that the underlying protocol actually supports control over Nagle-like functionality and (2) can be used to set Low Latency by default.

Any takers (@mwelzl @tfpauly?)... I could probably take a crack at this tomorrow...

@mwelzl

This comment has been minimized.

Contributor

mwelzl commented Apr 16, 2018

I'm not sure I like the name "Immediate" as a send property very much (because it conveys a meaning that we can't guarantee), but other than that I think you're right - we just need to convey "low latency" somehow and remove the "immediate ack" stuff. I don't think we need a protocol selection property for it.

@britram britram self-assigned this Apr 16, 2018

@britram

This comment has been minimized.

Contributor

britram commented Apr 17, 2018

+1 to "Immediate" not being the right name.

Ah, okay, I see what happened. The Immediate send property was subsumed into the (terribly named) Instantaneous Capacity Profile, and Low Latency in the protocol selection properties was subsumed into Capacity Profile.

If we keep Capacity Profile, then, the only action here is to remove Immediate Acknowledgement, and note that such functionality is implied by the Low Latency capacity profile. I'm leaning toward doing that for this issue, then starting a new issue for an (ietf-01) decision on what to do about Capacity Profile... is that good?

@mwelzl

This comment has been minimized.

Contributor

mwelzl commented Sep 12, 2018

It seems this has converged a long time ago... I'll remove the property about this from section A.1.3. That it's still there is just an oversight, I believe.

mwelzl added a commit that referenced this issue Sep 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment