Re: HTTP/3 Prioritization: kickstarting the discussion (again)

Hello Wesley,

Thank you for your messages.
While they seem to be full of ideas worthy of discussion, they do not seem
to relate to the original goal of this e-mail thread, namely to discuss
HTTP/3 prioritization in particular.
Feel free to open new e-mail threads to the mailing lists (both this one
(HTTP) and the one at quic@ietf.org, as a lot of what you say would be a
better fit for the transport layer imo) for your particular proposals.
You might also want to read up on existing work, seeing as several of your
topics have already been discussed in one form or another (e.g., QUIC
offloading to NICs, cleartext metadata in the QUIC header)

For this thread, I would appreciate it if we could keep it focused on
HTTP/3 prioritization.

Thank you in advance and with best regards,
Robin

On Mon, 8 Jul 2019 at 15:07, Wesley Oliver <wesley.olis@gmail.com> wrote:

> Hi,
>
> While my brain continues to mutate, solutions by quietly revisiting the
> same problems again and again, here are a few other things to note.
> Then just some other ideas if sparks anyone else mind on better solutions
> to things, or plants an idea.
>
> 1. Assuming reserved capacity on pipes, aka no congestion or contesting
> for router resource(async). Packet or datagrams that become corrupt or
> lost, we need a new real-time statistical probability model, that based on
> how bad the line is, pre-emptively re-transmit certain real-time
> events(packets/datagrams) so that we can have statistical probability that
> the event arrives at the client with absolute guaranty of maximum delay,
> that should be shorter than RTT.
> One would have to come up with probability modelling on a stream of data
> packets and that each should reach their destination, without corruption
> based on current states. Questions I can't think of an immediately obvious
> answer. How many packets should be between preemptive re-transmits, to
> ensure they don't get lost. There should be at least 3 repeat packets. Then
> what is the chance of the line going down? Potentially think of a heartbeat
> needing to sent with expected, amount of packets, so that if any are lost,
> that immediately real-time equipment knows there is a big problem and needs
> resync. Out of 3 duplicate datagrams, they are to receive in x microsecond
> from the previous. It tends to lead me to say that have transmitted and
> expect set of datagrams with payload or not to arrive in an expected amount
> of time if they expect don't arrive then we know there is a problem. The
> heat beat would have to communicate the timing of the expected packets
> ahead of time, that has to be transmitted with payload or without.
>
> 2. Reset services, contextually correct depending on uses case, so for
> performance recommend the following tweaks to rest.
> With regards to 404 and 203 Partial, the service should take a header
> param, which decided, If to return 200 or throw an error, this would allow
> the service to exposed as standalone external service or internally
> consumed one by another services business logic, by returning an empty set
> or null.
> The reason for this approach is a simple conditional check of whether to
> throw an error or return an empty list or null, is much faster than causing
> the unwinding of the call stack and waling to the point that there is error
> handler found.
>
> Throwing and catching an error is an expensive operation, so if we
> continue to throw and then having to catch those errors and then normalise
> them for business logic, in the consuming service is not great for
> performance.
>
> Thus s simple header param, is much simpler, better and faster.
> Ok passing the headers, may take a bit of time, if they are not short,
> so keep the names under 32bit/64bitwchar ( 4 characters)
>
> Header:
> -  -  -  -
> NoResultAsError = true
> PartialResultAsError = true
>
> 3.  Microservice architect ideas.. for those that may find it interesting.
> know not ideally the place..
>
> I have an idea I came up with on the weekend to address the issues, with
> regards to the fact that
> There is no single logical layer, with which we all communicate to ensure
> that the Business logical decision all the same.
>
> Typically when written a single instance of an application or internal to
> a microservice, we would have the following layers:
> Layers
> 1 DAL
> 2 Transaction Interlocking Enhancements/Authentication/Multi-user Editing.
> 3 BLL, Business Logic Layer (in which all complex exposed decision that
> all must consume)
> 4 Specific feature logic.
> 5 Then there are multiple presentation layers.
>
>
> The problem with micro service layer is that we need to all use the same
> business logic layer across all services,
> So the there is constancy in the definitions.
>
> Since we build a system that comprises of my different systems and 3rd
> party systems, in which we then aggregate and
> enhance simple fields to create more complex compounds decision by
> involving many fields of information.
>
> All these functions/endpoints need to exist in a single layer that is
> common across all microservice.
> How do we do this?
> 1. Implement a standard utility library, that consumes a set of up-stream
> endpoint, that only holds BLL logic. It would be a dependent module/package
> for the microservice, has to be kept up to date.
>
> 2. Enhance swagger endpoint definitions with the concept of private,
> public, protected, sealed.
> When loading swagger endpoint in the lowest upstream layer, an ms-service,
> generates a unique GUID to be injected between domain and postfix. i.e)
> vod-ms-digital-wallet/{Kubernetes}/DAL/{GUID}/{postfix}..
> With this, it creates a map for each ms from the {postfix} to live
> endpoint.
> i.e) {postfix} -> vod-ms-digital-wallet/{Kubernetes}/BLL/{GUID}/{postfix}..
>
> Then in all the services that consume this service, they are provided with
> lookup endpoint map, to the live instance.
> They use this lookup map to determine the correct ms-service endpoint
> address that they should be consuming.
>
> This service will then in the context of passthrough and all its specific
> enhancements, provide swagger definitions configuration specify which
> endpoint service to hide or expose, as per the traditional class-type
> access-modifiers tokens of public, private, protected, sealed.
> Producing a new map, were some endpoints terminate on this ms and others
> directly map to there passthought endpoints, so that there is no
> intermediate ms, to slow down due to layering.
>
> There is swagger definitions file for each consumed client services in a
> microserver, such that those methods can be exposed.
>
> All the micro-services that exist in the different layers, swagger
> definitions are aggregated, to detect conflicts in the access-modifiers
> discrepancies to the same consumed ms, if there are conflicts then need to
> resolve them as there two different microservice trying to modifier the
> base class in different ways. Were they now need to implement a new
> function/endpoint terminology loosely used)
>
> ---
> When hosting in the environment, for example, Kubernetes in the cluster.
>
> The layers would exist, those that write service in a specific layer,
> Are only allowed to consume service in the upper layer. If they try to do
> anything strange, they can't as they are forced to implement the logic in
> the correct consuming-layer. This pattern doesn't enforce them to implement
> the BLL in the BLL layer, and they could have out that in the presentation
> layer or client facing API, which is where it shouldn't live.
> Then again, there should be no conditional comparison with items, only
> filtering further up of this layer.
>
> So there would now be a difference between writing infrastructure code,
> which would be database, DAL, .. to pass thought BLL.
>
> One would be able to differentiate, what is BLL and what is feature
> specific ensures that all micro-service consume a single correct source of
> truth decision making BLL.
>
> ----
> The ability to put business logic in BLL utility library would mean that
> we could share that with frontend code and backend creating a greater
> consensus.
>
>
> On one other note also add a numerical to each layer name like,
> DAL-1000
> DAL-AUTH-TRANS-2000
> BLL-3000
> BLL-4000
> Presentation(PTL)-API-5000
> Presentation(PTL)-Frontend-6000
>
> So if we ever needed to implement intermediate layers, we have a
> reservation of like 1000 layers
> Between our current understanding of all our current layers required, we
> can then insert a new layer with a new ordinal(number) in the middle so we
> can still always insert new layers as required above and below.
> 500, 250, 125, 62, 31, 15
>
> 4. Look at having restify decoupled itself from HTTP, so pass a task back
> and forth where the endpoint name is now property.
> It would result in only one connection between different endpoints can be
> established and could use the base of quick as the communications protocol.
> Then use interprocessor memory to communicate work to workers, which
> hopefully would be much faster. Can also be exposed backwards compatibility
> as restify endpoint.
>
> On Thu, Jul 4, 2019 at 9:05 AM Wesley Oliver <wesley.olis@gmail.com>
> wrote:
>
>> Hi,
>>
>> I have to now play catch-up with all of this. South Arica great place for
>> employment, where boundaries can be pushed! Cough Cough!! More like
>> unemployment, rubbish and constructive dismissals..
>>
>> Just maybe two things that I could highlight, with regards to hope that
>> the new spec addresses these things some were. I am going to have very
>> quickly over this weekend come through everything,
>> and then I will know for sure. But at least this would high live design
>> requirements I would like to see QUICK and http address.
>> However, I see that the draft is near a closing.
>>
>> I would separate QuickHttp into to different layers, which thing it is,
>> current..
>>
>> 1. Quick Transport, Reliability, Address Buffer Bloat for real-time
>> communications.(Gaming/Voice/Robotics)
>>
>> 1.1 Payload at Datagram and Packet-Level, by using a prioritization byte,
>> which which is easily accessible to router hardware
>> to inspect, allowing data in router queues, to be interlace differently,
>> No longer FIFO, which would address buffer bloat.
>>
>> 1.2  This would allow for true real-time communication below QoS, that
>> the application can control, so for my gaming communication
>> I can send data image payloads of custom decl and then priorities, voice
>> traffic in coms channels over my data traffic, then prioritize a set of
>> events
>> over the voice traffic. Example: Kill event, should have priority over
>> location event and event environment change, so distributed consense
>> algorithm can be even more accurate when there is congestion.
>> This would allow real-time communications, were wired networks versus
>> wireless networks can experience sudden and massive impedance mismatches,
>> causing
>> massive packet loss in the last mile of connection, by allow real-time
>> priority byte, copious amounts of data and be buffer at a Base Station,
>> while still being flushed,
>> without needing to retransmit packets over the whole internet, for the
>> origin. LTE should allow mobile to communicate, a priority of how it would
>> like all communications, to be flushed out to it,
>> base on the handset current positions.
>>
>>
>> 1.3 The protocol must support direct memory access writing to NIC's, so
>> that we can improve hardware internal bandwidth.
>> This would require two buffers, main head buffer and a data buffer. The
>> main header buffer holds reference from there the NIC should
>> read and flush the data out of NIC. Either from direct memory reference
>> range or range in the data buffer.
>> One important thing to remember here is that there needs to be the
>> ability to dynamically change the priority of the flushing
>> as new async resource or events are produced, So basically then need
>> another micro Priority tree from were
>> to full and flush all the data from.
>>
>> 1.4 Ensure that AK and NAKs which have to be sent of the upstream, can
>> get caught up in congestion of the upstream, decoupling..
>> Maybe QoS identifier for AK and NAK packets, so that easily can shape the
>> traffic, so that the downstream doesn't get impeded by its dependence
>> on the upstream.
>>
>>
>> 2. Http 3.0, where the server can flush async resource dynamically as
>> they become available.
>>
>> 2.1 Support for advance pagination hinting, the example below:
>>
>> The traditional approach to pagination:
>>
>> DefaultPageSize=25
>> --
>>
>> Request:
>>
>> Get http://...?Page=5
>>
>> Headers: normal..
>>
>>
>> Response: 25 Items traditional
>> ---
>>
>> Repeat... or change the page size in the request, but this prevents good
>> use of caching all round.
>>
>>
>> New Approach:
>>
>> DefaultPageSize-25
>> --
>>
>> Request:
>>
>> Get http://...?Page=5
>>
>> Headers: Hint-PageSize=200
>>
>> ---
>>
>> Server, reconise page hint, and pulls 200 align records to Page 5,
>>
>> It then response with 25 IItems, like traditional repsonse to the Get
>> request.
>> Then pushes Page6 throught to 5 + 200/PageSize (8) = 12 as seperate
>> repsonse
>> in the minor granularity of 25 Items a page.
>> Push: get http://...?Page=5
>> Push: get http://...?Page=6
>> Push: get http://...?Page=7
>> Push: get http://...?Page=8
>> Push: get http://...?Page=9
>> Push: get http://...?Page=10
>> Push: get http://...?Page=11
>> Push: get http://...?Page=12
>>
>>
>>
>> To prevent any race conditions, request from the client, responding to a
>> page request while still inflight, If there
>>
>> server detects it is still pushing it, while it has yet to get AK for
>> completion, it will just ignore the request or transmit a repsonse or
>>
>> inflight for debbugging..  This would allow the client to just match out
>> going with income requests while in flight.
>>
>>
>>
>> This could be difficault if one was to parrallel async all the page
>> request, because then, need to have a Batch Request Header, so server align
>> the requests.
>>
>> So somthing like this:
>> Headers:
>> - BatchRequestGuidGroupID:
>> - BatchRequestFirstPageSequence:
>>
>> This would allow mutiple http parrallel request to the server, to figure
>> out which pages to return as pushes..
>>
>>
>>
>> 3. Cisco and equipment manufacture..
>>
>> 3.1 Implemented more advance sub QoS queuing management in quick.
>> 3.2  Implemented the ability or ensure that this can be dynamically
>> reserved Different capacities. aka shapping, however,
>> interlace packets at specific reserver bandwidth allocations, to preserve
>> real-time communications and video quality.
>> Video:50%, BandWidth reserver at client level, based on the subscription
>> of 40Mbits dedicate reserved bandwidth to video server across the internet
>> for them,
>> whether use or un-used, that paying a premium for a bandwidth reserve for
>> there 4K video T.V. No more downscaling when congestion.
>> Calls: 20%, no more gitter and call break up.
>> Gaming:20%
>> Data: 10% -  What can happen here, loads of congestion.
>>
>> Basically, per connection endpoint of fibre, there is profile, that the
>> backbones would have to look up the video subscription of bandwidth pipe
>> reserver that is being paid for
>> , then dynamic reserve that bandwidth, when detect connection being
>> opened in the video space.
>>
>> 3.3 Implemented new bandwidth handling for AK's and NAKS packets on the
>> upstream because congestion of the upstream will result in reducing ak and
>> increased RTT.
>> Otherwise, the downstream gets impeded and will not achieve max
>> bandwidth, because it is dependent on the upstream congestion, the two have
>> yet to be decoupled...
>> as far as I know, can see.
>>
>> 4: 6G
>>
>> 4.1 To implement a datagram level flushing priority mechanisms that the
>> handset can communicate to the BS, based on what the current user is doing.
>>
>> 4.2 Address congestion of upstream NAK and AK, using TMDA or somthing
>> more impressive, so that downstream bandwidth is not constrainted by a
>> dependancies on the upstream AK/NAK
>>
>>
>> That is everything that I know to be a current problem...
>> Can forward hackathon suggestion to Vodacom too.. for the CISCO and
>> dynamic pipe reservation for traffic on pipes..
>> I hate bad quality video and down sampling.
>>
>>
>> Sorry I catch up!
>>
>> Kind Regards,
>>
>> Wesley Oliver
>>
>> On Wed, Jul 3, 2019 at 6:11 PM Robin MARX <robin.marx@uhasselt.be> wrote:
>>
>>> Hello everyone,
>>>
>>> As I expect most of you know, there has been quite a bit of talk over at
>>> the QUIC / HTTP/3 working group recently on what to do with the dependency
>>> tree / prioritization system from HTTP/2 in H3.
>>>
>>> There are two major issues:
>>> - There a a few subtle HOL-blocking issues in porting the system to H3
>>> due to the way streams work in QUIC
>>> - Quite a few people feel H2's approach is overly complex and can/should
>>> be simplified
>>>
>>> For now, the QUIC wg has taken the stance to try and stay as close to H2
>>> as possible (e.g., exclusive priorities had been removed before, but are
>>> now back in the editor's draft of HTTP/3).
>>> The QUIC wg wishes to see more real implementation experience and
>>> experimental results for new proposals before considering them. It also
>>> feels this issue is best discussed in the httpbis wg. And thus we come to
>>> this email.
>>>
>>> We have been recently running some prioritization experiments for a
>>> variety of schemes and proposals using our own HTTP/3 implementation in the
>>> Quicker project.
>>> We have discussed our findings in a paper, which you can find in
>>> attachment and also on https://h3.edm.uhasselt.be.
>>>
>>> The paper attempts to provide a rather extensive discussion of the
>>> issues with H2's setup, H3's approaches so far and the alternative
>>> proposals that have been made.
>>> As I appreciate not everyone has the time to read all of that, our main
>>> findings are:
>>>
>>> 0) The current proposal (which should be "draft-21" soon) for HTTP/3
>>> works well in practice, though the semantics of the "orphan placeholder"
>>> might still need to be tweaked a bit.
>>>
>>> 1) Simpler setups are also perfectly viable.. The main contender, from
>>> Patrick Meenan (
>>> https://github.com/pmeenan/http3-prioritization-proposal/blob/master/README.md)
>>> would be a good candidate for this.
>>>
>>> 2) However, there is no single scheme that produces ideal results for
>>> all web pages (e.g., the scheme that is best for page A can perform really
>>> badly for page B). So dropping everything for a single, simpler approach is
>>> potentially sub-optimal. Similarly, the current approach of browsers of
>>> just using a single scheme for all pages might need revision.
>>>
>>> 3) Ideally, we should thus allow the scheme to be tweaked per-page,
>>> either via a mechanism where the server indicates the optimal scheme to the
>>> client (which we propose in the paper), or where the client communicates
>>> additional metadata to the server (e.g., resource is blocking/non-blocking,
>>> can be processed progressively, ...) to make server-side prioritization
>>> easier (Kazuho Oku is working on a proposal for this, but doesn't feel it's
>>> ready to share here yet).
>>>
>>>  4) In order to make progress on H3, it's probably best to stick with
>>> the draft-21 approach (potentially with a few more small tweaks) and define
>>> a new approach as an extension or implement it at the higher HTTP layer
>>> (i.e., as HTTP headers, rather than H3 frames). However, would that then
>>> find enough adoption fast enough...
>>>
>>> While I'll be the first to admit our study isn't terribly extensive or
>>> fully realistic (we tested 40 pages in lab settings without a real
>>> browser), I still feel our results are enough to have a basis to continue
>>> the discussion on. We of course encourage others to share their results as
>>> well.
>>> Some more background information can be found here as well:
>>> https://github.com/quicwg/wg-materials/blob/master/interim-19-05/priorities.pdf
>>>
>>> I'm a bit unsure what the best questions are to ask at this point, but
>>> some attempts:
>>> - Are implementers willing to implement 2 completely different
>>> approaches (1 for H3, 1 for H2)?
>>> - Are (browser) implementers willing to consider supporting multiple
>>> schemes (specific trees)?
>>> - Are (server) implementers willing to create/support more complex
>>> (user-driven) server-side prioritization config/APIs?
>>> - How important is it to move to a simpler (and thus less flexible)
>>> setup?
>>> - Should this be a blocker for HTTP/3 or not?
>>>
>>> Looking forward to your feedback.
>>> With best regards,
>>> Robin
>>>
>>> --
>>>
>>> Robin Marx
>>> PhD researcher - web performance
>>> Expertise centre for Digital Media
>>>
>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>>>
>>> www.uhasselt.be <http://www.uhasselt..be>
>>> Universiteit Hasselt - Campus Diepenbeek
>>> Agoralaan Gebouw D - B-3590 Diepenbeek
>>> Kantoor EDM-2.05
>>>
>>>
>>>
>>
>> --
>> ----
>> GitHub:https://github.com/wesleyolis
>> LinkedIn:
>> https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
>> Blog/Website:https://sites.google.com/site/wiprogamming/Home
>> Skype: wezley_oliver
>> MSN messenger: wesley.olis@gmail.com
>>
>
>
> --
> ----
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com
>


-- 

Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05