search

ietf-tapswg / api-drafts

Architecture, interface, and implementation drafts for the definition of an abstract API for IETF TAPS
Other
23 stars 15 forks source link

Rename either Conn. or Msg. Niceness #228

Closed mwelzl closed 5 years ago

mwelzl commented 6 years ago

I suggest: Connections have Priorities Messages have Niceness

Also, for Message Niceness (if that's the name that stays), we need to clarify that this can, for example, influence how messages are ordered in the send buffer (as per Mirja's suggestion).

This issue is the result of the discussion on Niceness at the interim. See: https://etherpad.tools.ietf.org/p/notes-ietf-taps-interim-2018-09-12

philsbln commented 6 years ago

I think Priorities and Niceness are just a sign issue, and are not the right way to distinguish between per-message or per-connection/per-stream priorities.

While I like the notion of "niceness", I think calling both priorities makes it easier to describe the difference between message priority and stream priority. The exact interaction between both should be declared unspecified, while we should give explicit examples of how the individual priorities map to protocols and interact with other properties like "ordered".

If we have protocol-specific interactions, they should be captured by protocol-specific properties.

britram commented 6 years ago

While I like the notion of "niceness", I think calling both priorities makes it easier to describe the difference between message priority and stream priority. The exact interaction between both should be declared unspecified, while we should give explicit examples of how the individual priorities map to protocols and interact with other properties like "ordered".

This makes sense; however, the sign issue (do priorities go from 0 down or from 0 up?) is not merely a stylistic choice. Post did these 0-down for a reason. Unless the number of priority classes is itself a connection property, ISTM that it's much easier to dynamically handle 0-is-max as opposed to 0-is-min priority. In the former case, any new (higher numeric) priority the TAPS system has not yet seen on a connection must yield to all others, while in the latter, any new (higher numeric) priority must cause all other pending stuff to yield. The former seems easier to implement...

mwelzl commented 6 years ago

I have no strong opinion on the choice of Niceness vs. Priority, though I also see Phil's point. @britram about the implementation benefit - I understand what you say here but I still can't see why this would make it easier to implement. Can you give a concrete example for how this would make things easier?

mwelzl commented 5 years ago

@britram ping

britram commented 5 years ago

so presume that you have N queues or transmission treatments configured, and someone starts sending with open-ended highest-wins integer priority N. Okay, cool, assign to highest priority queue. Now what happens when priority N+1 is used? do you shift all the other senders down one?

with niceness (open-ended lowest wins), the application developer is kind of forced to think in terms of "what is my highest priority stuff" at the beginning.

most APIs I know of here has closed-ended priority classes, which is why they sidestep this problem.

(That said, most of my preference for niceness is aesthetic -- we've had mixed success with wide deployment of "do non-default stuff to make it Go Faster", so "do non-default stuff to yield" might work out better...)

britram commented 5 years ago

not sure that's much beyond a restatement of my october comment though.

mwelzl commented 5 years ago

That's still abstract. Regarding this:

Now what happens when priority N+1 is used? do you shift all the other senders down one? I'd say yes, and I can't see an implementation difference.

For most (reasonable) scheduling algorithms, I don't think there's a difference if the new unseen value is high or low, as it has to affect the probability of taking something from the queue for every other queue anyway. Or take the credit-based scheduling that's loosely described in https://tools.ietf.org/html/rfc8298#section-4.1.2.8 - here, a decision about giving a lot of credit or not so much credit to a new stream is made. Whether an implementation maps "large value from the API" to "lot of credit" or "large value from the API" to "little credit" doesn't really make a difference, does it? In can definitely say that it makes no difference in approaches like our cc. coupling in draft-ietf-rmcat-coupled-cc: here we use the sum of all priorities to calculate the priority share that everyone gets.

Regarding aesthetics, my argument pro "priority" is that a priority is a much more common concept in protocols than "niceness" (e.g. also QUIC talks about "Stream Prioritization" and not "Stream Niceness"). As for "non-default stuff making it Go Faster" or not, implementations can define these things as they want, they could also limit priorities to a range of 0-1, then no new value will be "non default"? Bottom line, IMO, this is not really about non-default, it's just a number coming from the application, nothing more.