Closed mwelzl closed 6 years ago
philsbln
commented
6 years ago I agree that the name "Niceness" is a Unix artefact. But its usage hides an important design decision:
abrunstrom
commented
6 years ago The scope is a single connection/connection group so I do not think that a priority above-normal would be a problem, so I prefer priority. But also not sure that we need this feature. I think having priority on a connection level is sufficient.
tfpauly
commented
6 years ago Connection-level priority is important, and must be there. As commented elsewhere, this allows prioritization between multiplexed connections, as well as when connections are sending packets through a common interface that may have a local AQM.
However, that's not what the Niceness property on a send/receive is. That's the priority of a piece of content relative to other content on the connection. If I am using an unordered protocol, then my content may be re-ordered within a single connection. Having a relative priority of content is useful.
This does not need to necessarily be within the "transport protocol's send buffer": I would implement this at the layer that processes send calls and schedules them into the send buffer. While moving content into that send buffer, I would re-order the content based on priority.
So, I agree that per-connection (and thus per-QUIC-stream for example) priority is more important, I don't think that it is necessary to remove a per-content priority.
britram
commented
6 years ago First, I personally tend to think that priority (at all) is a little superfluous. This was in Post Sockets for completeness.
The point of this being per-Content is to support Protocol Stacks that use multiple streams / multiple paths transparently behind a single Connection to decide which stream or path to use.
The point of it being reversed, and not called "priority", is more philosophical. Most of how we think about priority in transport came straight from the old ToS byte, which itself was meant to implement US DoD requirements for trunk line access in a nuclear emergency. This doesn't map to how applications think of transport, in part because of the APIs we've had to date: there's either "this really really needs to get there because it's an interactive ^C" (URG), "normal", and "I care a bit less than normal" (PR or unreliable).
"Niceness" is a little UNIXy. How about "yield" if we end up keeping it?
OTOH per-Connection priority restricts Protocol Stack implementations enough that I'd rather just ditch priority in the core API altogether rather than explicitly making it a Connection property.
mwelzl
commented
6 years ago Well, to me "more important = higher priority number" has always been more natural, but I'm definitely not going to fight for this. Anyway, "yield" is worse, IMO, by just making this even less intuitive than "niceness" which some people may understand / appreciate for its Unix heritage.
What's more important is what this really does. I agree that we want priorities for multiple streams, but that's the same as per Connection, as your Connections may end up being streams! Hence I don't understand your last paragraph at all.
Per-Content just means that, even on a single transport connection, you could have different Niceness values, and that doesn't seem extremely useful to me.
britram
commented
6 years ago ...but that's the same as per Connection, as your Connections may end up being streams
Maybe. Just because we can support one PSI stream per Connection, doesn't mean that we must only do so.
Per-Content just means that, even on a single transport connection, you could have different Niceness values, and that doesn't seem extremely useful to me.
It's primarily useful in two specific instances:
Arguably, Lifetime is enough for point 2, and 1 might be rare enough that it's not worth exposing.
mwelzl
commented
6 years ago ...but that's the same as per Connection, as your Connections may end up being streams Maybe. Just because we can support one PSI stream per Connection, doesn't mean that we must only do so.
Ah, I get it. Two niceness values on two Content blocks on one Connection means that maybe, below, you're opening two streams and scheduling between them.
Per-Content just means that, even on a single transport connection, you could have different Niceness values, and that doesn't seem extremely useful to me. It's primarily useful in two specific instances:
with single-Connection, multiple-Stream protocol stacks, to note that "nicer" content shouldn't HoL >block normal (or less-nice) content with partially-reliable transports, to give additional input to the transmission scheduler about what >should be (re-)transmitted first Arguably, Lifetime is enough for point 2, and 1 might be rare enough that it's not worth exposing.
Yes - these are the "not extremely useful" things I had in mind... they're reminiscent of stuff like this: https://tools.ietf.org/html/rfc7496#section-4.2 ... which always has the alternative of: don't put so much logic down there and leave the application in control (provided you have some good form of back-pressure, which we now have).
Anyway, I think you have convinced me with the first argument.
"Niceness represents an unbounded hierarchy of priorities of Content, relative to other Content sent over the same Connection and/or Connection Group". Let's consider "Connection": then this is about assigning a higher priority to a piece of Content than to a previously submitted piece of Content? What, to be sent earlier? This is re-scheduling inside the send buffer - generally, there are two ways to do these things: 1) complex, inside the send buffer; 2) more flexible, by allowing the application to manipulate its data until the last minute and be informed about the buffer running dry. I think we should definitely prefer the latter.
About other content within the same Connection Group: I could see a possibility of implementing a per-Content Niceness value here, by continuously changing the priority assigned to a connection in a group.
Finally, "Niceness may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization." => priorities on the wire: would this control the DSCP? But I think we have clear advice to not permanently change the DSCP on the same connection.
To conclude, I think the idea of per-Content Niceness should be dropped, and Niceness should only be assigned to a connection.
Finally, I'm not a fan of the "Niceness" term. Priority seems clearer and easier to me, while I see "niceness" as a Unix artifact... but that's a matter of taste.