Re-prioritizing requests that have started a transmission

[ddragana]

If neqo has started transmitting data on a stream, should it change its priority?

It is better to finish sending a request so that the server can actually respond to it. In most cases the server can only serve a request when it is completely received. Probably for the short requests (most common request on the web), neqo should prioritize requests that have already been started. Uploads, on the other hand, should be possible to re-prioritize and interleave it with other requests.

[martinthomson]

Are you trying to decide if re-prioritisation is wasteful in these cases? Keep in mind that sometimes requests might have been buffered, but not sent. Priority will determine when the request is sent. It will also determine when retransmissions occur.

I infer from the issue that you aren't thinking about signalling, just the local priority marking. But that is cheap to apply. The only cost is, as you say, if we end up sending many partial requests, which are not useful to servers. Maybe we could get data: how often would re-prioritisation lead to a request being incomplete? Most are small enough that it seems unlikely that this would happen.

Also, just making a new request at a higher priority could mean that a partial request is made. So we can get into that state without supporting re-prioritisation.

Finally, it might make sense to put uploads on a different schedule. Say we waited for the header block to be acknowledged and then we drop the priority of the upload. That would keep the connection available for other requests. We could do that for any request that still has data to send when the header block is done.

[ddragana]

Are you trying to decide if re-prioritisation is wasteful in these cases? Keep in mind that sometimes requests might have been buffered, but not sent. Priority will determine when the request is sent. It will also determine when retransmissions occur.

I infer from the issue that you aren't thinking about signalling, just the local priority marking. But that is cheap to apply. The only cost is, as you say, if we end up sending many partial requests, which are not useful to servers. Maybe we could get data: how often would re-prioritisation lead to a request being incomplete? Most are small enough that it seems unlikely that this would happen.

Yes, I am not talking about signaling only about local scheduling of requests. I am also only talking about the client side as it is more important to us. As you said I do not expect that this will happen very often, but on a bad network it may happen. Necko already have knowledge about which tab is focused and internally does de-prioritization of requests from background tabs. I was thinking to experiment with this at some point and this could lead to many partial request on a bad network.

My idea was to set a higher priority for requests that are already partially sent. This should only happen for short requests not uploads.

Also, just making a new request at a higher priority could mean that a partial request is made. So we can get into that state without supporting re-prioritisation.

Finally, it might make sense to put uploads on a different schedule. Say we waited for the header block to be acknowledged and then we drop the priority of the upload. That would keep the connection available for other requests. We could do that for any request that still has data to send when the header block is done.

Yes, we should make sure that uploads do not starve other requests.

[martinthomson]

My idea was to set a higher priority for requests that are already partially sent. This should only happen for short requests not uploads.

This should already happen. We process streams in a strict order (creation order even), so I don't think we need to do anything special there, until you reprioritize. I would simply say that you might suppress reprioritization for requests that have had bytes sent (we don't expose that information now at the transport, but we could).

All of this gets a little less clear if we are blocked on flow control, but I don't think we need to think too hard about that case. Retransmissions are already bumped up in priority so that is no problem.