Re: Results from adopting HTTP/3 priority

I should also note that part of the experiment result (the critical API experiment mentioned in Alan’s email) was done without scheduling fresh data and loss data together. Back then, loss data were scheduled separately, before fresh data, but still respect to priority. In other words, we used to send high pri loss data, then low pri loss data, then high pri fresh data, then low pri fresh data. Then we switched to this new scheduler, where it first sends high pri loss data, then high pri fresh data, then low pri loss data followed by low pri fresh data. I didn’t see any interesting metrics move since this change though.

Yang

From: Yang Chi <yangchi@fb.com>
Date: Tuesday, April 27, 2021 at 11:22 AM
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, Alan Frindell <afrind@fb.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Results from adopting HTTP/3 priority
Hi,

Yes we consider priority level for retransmitting lost bytes, that is, the bytes are marked as real loss. Fresh data and loss buffer are scheduled together in our QUIC transport with respect to streams’ priorities. For PTO, we don’t consider priority.

Regards,
Yang

From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Monday, April 26, 2021 at 9:19 PM
To: Alan Frindell <afrind@fb.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Yang Chi <yangchi@fb.com>
Subject: Re: Results from adopting HTTP/3 priority
Hi Alan,

On Mon, 26 Apr 2021, 16:35 Alan Frindell, <afrind@fb.com<mailto:afrind@fb.com>> wrote:
The Instagram app for Android recently adopted HTTP priorities for HTTP/3 requests and I wanted to share our positive results with this group.

Thanks for sharing your findings. This is some valuable feedback.

Since you mention HTTP/3, I have a question about retransmission. It's not a part of HTTP priorities per se but does your implementation consider priority level for scheduling retransmission?

Cheers
Lucas