Be less specific about urgency when behind an intermediary #1264
Conversation
|
cc @martinthomson, since it closes your issue. |
draft-ietf-httpbis-priority.md
Outdated
| the intermediary as another signal in its prioritization decisions. For | ||
| instance, if a server knows the intermediary is coalescing requests, then | ||
| it could prioritize responses using a fixed urgency level with incremental | ||
| loading. Treating all requests from an intermediary in this way would result in |
There was a problem hiding this comment.
I don't know why you would recommend incremental loading at all. You might just say "assign all requests the same priority". And then add the note about where the bottleneck is.
There was a problem hiding this comment.
In this context, incremental means round-robin. We don't care how the thing receiving the response processes it. But we do want to avoid the server responding as FIFO, which might cause a different type of fairness problem.
There was a problem hiding this comment.
Knowing that the intent of this PR is to be less specific, I think we can get rid of suggestions that refer to the specification (i.e., use of words like "urgency" and "incremental").
Rather, we can condense this sentence and the following one to something like: For instance, if a server knows that the intermediary is coalescing requests, it could serve the responses in round-robin.
draft-ietf-httpbis-priority.md
Outdated
| round-robin scheduling. This works well when the network bottleneck exists | ||
| between the intermediary and the end client, as the intermediary buffers |
There was a problem hiding this comment.
This assumes that the network is always the bottleneck. Sometimes it is processing resources that are being prioritized.
This can work if the constrained resource is network capacity between the intermediary and user agent.
(End client == user agent?)
draft-ietf-httpbis-priority.md
Outdated
| dynamic urgency that more closely reflects request urgency, in order to have | ||
| weighted round-robin scheduling. This would result in less urgent responses |
There was a problem hiding this comment.
I'd drop the last two sentences entirely. Statements about sophistication will likely seem quaint in 6 months time.
There was a problem hiding this comment.
What about condensing the two to say "Weighted round-robin scheduling could improve the use of contained network capacity further."?
There was a problem hiding this comment.
I think my preference goes to removing the last two sentences, due to the following reasons:
- Use of WRR degrades fairness, and might have negative impact on perceived performance of an end user.
- This is a problem that we do not need to solve now. Our choice of two priority parameters has been based on what we want to have for web browsing. For web browsing, we do not expect to see the case being described here.
|
I believe this is now good to go, please approve or speak up if you disagree. |
Closes #1022