Subject: HTTP(3) priorities

From: Ian Swett <[email-masked]>
Date: Tue, 9 Jul 2019 21:00:06 -0400

There has been quite a bit of discussion of HTTP priorities lately on both
the QUIC and HTTP mailing lists, with more to follow.  The plan for IETF in
Montreal is as follows:

   - Monday: Overview of priorities for 15 minutes in HTTP, with 15 minutes
   discussion.
   - Wednesday: A side meeting will be held from 8:30-9:45am in Van Horne.
   - Thursday: I'll summarise the side meeting in Wednesday's HTTP session.

Thanks, Ian

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 24 Jul 2019 13:14:55 -0400

Hi!

Attached are the slides that Lucas and I presented during the side meeting.

Thank you all for the feedback.

2019年7月9日(火) 21:00 Ian Swett <ianswett=[email-masked]>:
>
> There has been quite a bit of discussion of HTTP priorities lately on both the QUIC and HTTP mailing lists, with more to follow.  The plan for IETF in Montreal is as follows:
>
> Monday: Overview of priorities for 15 minutes in HTTP, with 15 minutes discussion.
> Wednesday: A side meeting will be held from 8:30-9:45am in Van Horne.
> Thursday: I'll summarise the side meeting in Wednesday's HTTP session.
>
> Thanks, Ian

-- 
Kazuho Oku

---

From: "Oliver, Wesley, Vodacom South Africa (External)" <[email-masked]>
Date: Thu, 25 Jul 2019 06:48:18 +0000

Hi,

The only thing I could suggest is that you make those priority flags increments of 20,
So that if there are changes or minor priority preference per website, then
That in between numbers can be used. If there is any new future priority conventions
Then just add them in the middle of the 20 group splitting the existing group.
Maybe make the field 2 bytes, which allows for future expansion, were there are many files, streams
Which require a new priority order.

Otherwise one needs to build a priority map, over the deps, converting a high resolution to low resolution.

Kind Regards,

Wesley Oliver

> On 24 Jul 2019, at 19:14, Kazuho Oku <[email-masked]> wrote:
>
> Hi!
>
> <The Priority Header Field.pdf>

This e-mail is classified C2 - Vodacom Restricted - Information to be used inside Vodacom but it may be shared with authorised partners.

"This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this linkhttps://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy"

---

From: "Oliver, Wesley, Vodacom South Africa (External)" <[email-masked]>
Date: Thu, 25 Jul 2019 12:39:56 +0000

Hi,

One other thing to consider with the priority header byte that exists I the frame, is that
The orchestrator of the priority header values, needs to be able to identify when it can re-use
A priority header value, to deal with the fact all buffers in route, are required to have been flushed and empty,
So that there are no duplicate or old state datagrams in route, which can be put ahead of the new information data frame
Reusing that priority value. May there should be a flush frame, but there is no guarantee, goes sought the same route , so that wouldn’t work.

A TTL won’t work, because we want to support large buffers.

So routers, would have to detect sequence frame numbers, being re-cycle for stream-priority pair,
Then drop all stale packets. This means that each frame sequence number must be increasing even for drop frames, packets.
Sequence number can only be recycled if, AK has been received for specific sequence number.
This means that the larger-buffer will be limited respectively by sequence number size 2bytes times data frame payload size,
Before blocking will be experience and there sender will stall, having to wait for the buffers to be flushed, so it can get an AK from a frame in flight.

2^16 * (dataframe payload size) = max buffer size.

Ideally the sequence number if going to be used, needs to be large to support massive buffers with out AK blocking on the window as in tcp.
Assuming that window size here is unlimited, which what would be ideal for massive files and streams, were rather can re-read with Direct memory access the data for restransmission of lost packets.

If don’t have sequence number, which is highly unlikely, the larger priority byte would bee need to avoid collisions for inflight traffic.

My feeling is that sequence number + priority number should be used and should be larger enough, to support unlimited window size for AK,
So routers will truly know a frame correct re-transmission ordering.

Maybe allow MSB of the sequence number or potentially priority frame to extend the size in bytes 1,2,4,8,12,14,16,18,20.
Ideall look at the total buffer data size, that the sequence number would allow to be transmitted and considered inflight,
Before blocking would occur.

Kind Regards,

Wesley Oliver

> On 25 Jul 2019, at 08:48, Oliver, Wesley, Vodacom South Africa (External) <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Oliver, Wesley, Vodacom South Africa (External)" <[email-masked]>
Date: Thu, 25 Jul 2019 12:45:31 +0000

One last thing, if the frame is to remain simple for router inspection, then also required Quality of Service byte, to be exposed
At frame level, so AK and NAK different controls mechanism of the transmission, which will throttle and block the transmission in the opersite direction can be prioirized over more general QoS.
NAK AND AK, should have priority over all internet traffic.
So then a frame that is to be transparent should consist at least of

 QoS, priority, Sequence number
in this order from left to right, for the byte order to be good for router
Interpretation for queuing and interlacing of frame traffic.

Kind Regards,

Wesley Oliver

> On 25 Jul 2019, at 14:39, Wesley Oliver <[email-masked]> wrote:
> 
> Hi,
>

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 26 Jul 2019 09:48:21 -0400

Hi Oliver,

Thank you for your comments.

Being a server developer, I like the idea of splitting the urgency
groups, but I am not sure if we should bake something that we *might*
want to use into the core design. IIUC, your suggestion is to have a
more fine-grained signaling between the web application and the H2/H3
terminator. Assuming that is the case, these two parties can do an
experiment, by defining a proprietary parameter of the Proxy header
field, do the experiments, then ask for it to become an official
extension.

Now that we are dropping support for priorities in H3, it is
beneficial to have some alternative shipped at an early moment.

Therefore, it is my view that we should first standardize something
minimally viable, based on what the clients and servers already do, at
the same time leaving room for experiments and improvements. While I
agree that having 20*8 urgency levels is possible, it is complex than
just having 8 urgency levels. Broad adoption of the H2 prioritization
scheme happened, even though it was implementable. At least two
large-scale server operators do support it the way spec is written.
But for others, it seemed too complicated. I think we would like to
minimize the chance of repeating that failure.

Regarding your other comments, I am not sure if I am following, but I
do not think that routers or switches would deal with the HTTP-level
priority information. Plaintext H2 is not a thing, and H3 will always
be encrypted. It is also my understanding that sending some packets of
a connection with a different QoS label is a bad idea, because doing
so would have bad impact on loss recovery and congestion control. I
could be wrong (or there might be some solution that I am not aware of
- I'm not a transport persone), though.

-- 
Kazuho Oku

---

From: "Oliver, Wesley, Vodacom South Africa (External)" <[email-masked]>
Date: Mon, 29 Jul 2019 06:47:13 +0000

Hi,

Ideally the payload should be encrypted!
Any form of priority flags and Oos and steamID should be publicly readable, so that routes and switches
Can deal with buffer bloat at the data frame level.

Well with out quality of service, you subject to router packet inspection, and congestion and re-transmission
Rules that are custom to that router. Any isp can shape traffic how they like, so Qos, just way to improve the a realtime reverse pipe
Across network segments, to ensure the use has the correct realtime experience.
So to just claim the Qos effects it, is not correct, there so many other external factors that would affect it.

Kind Regards,

Wesley Oliver

> On 26 Jul 2019, at 15:48, Kazuho Oku <[email-masked]> wrote:
> 
> Hi Oliver,
>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jul 2019 19:32:04 +0000

Whatever we design will likely be used with both HTTP/2 and HTTP/3.

HTTP/2 is TCP, so delivering segments in priority is... inadvisable.

HTTP/3 is QUIC, where the application data is encrypted.

In neither case is it possible (or advisable) to put unencrypted application-level priority fields outside the encrypted envelope.

-----Original Message-----
From: Oliver, Wesley, Vodacom South Africa (External) <[email-masked]> 
Sent: Monday, July 29, 2019 2:47 AM
To: Kazuho Oku <[email-masked]>
Cc: Ian Swett <ianswett=[email-masked]>; IETF QUIC WG <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: [WARNING: ATTACHMENT(S) MAY CONTAIN MALWARE]Re: HTTP(3) priorities

Hi,

Ideally the payload should be encrypted!
Any form of priority flags and Oos and steamID should be publicly readable, so that routes and switches Can deal with buffer bloat at the data frame level.

Well with out quality of service, you subject to router packet inspection, and congestion and re-transmission Rules that are custom to that router. Any isp can shape traffic how they like, so Qos, just way to improve the a realtime reverse pipe Across network segments, to ensure the use has the correct realtime experience.
So to just claim the Qos effects it, is not correct, there so many other external factors that would affect it.

Kind Regards,

Wesley Oliver

>> The only thing I could suggest is that you make those priority flags 
>> increments of 20, So that if there are changes or minor priority 
>> preference per website, then That in between numbers can be used. If 
>> there is any new future priority conventions Then just add them in the middle of the 20 group splitting the existing group.
>> Maybe make the field 2 bytes, which allows for future expansion, were 
>> there are many files, streams Which require a new priority order.
>>

---

From: Nico Williams <[email-masked]>
Date: Mon, 29 Jul 2019 15:59:29 -0500

> Ideally the payload should be encrypted!

The metadata should be as well.