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

From: Robin MARX <[email-masked]>
Date: Wed, 3 Jul 2019 16:26:02 +0200

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
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: Patrick Meenan <[email-masked]>
Date: Wed, 3 Jul 2019 12:27:20 -0400

I don't know if we want it as an explicit goal but one of the main reasons
for my initial alternative proposal was that it is stateless which makes it
easier for application logic outside of the connection-owning code to
reason about and influence prioritization. That can always be handled by a
translation from something proprietary into a tree at the actual connection
but having both sides speak the same stateless model makes it a lot
cleaner.

On Wed, Jul 3, 2019 at 12:11 PM Robin MARX <[email-masked]> wrote:

> - 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).
> 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.
>
> 1) Simpler setups are also perfectly viable.. The main contender, from
> Patrick Meenan (
> I'm a bit unsure what the best questions are to ask at this point, but
> some attempts:
> www.uhasselt.be <http://www.uhasselt..be>

---

From: Wesley Oliver <[email-masked]>
Date: Thu, 4 Jul 2019 09:05:17 +0200

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

-- 
----
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: [email-masked]

---

From: Wesley Oliver <[email-masked]>
Date: Thu, 4 Jul 2019 13:48:33 +0200

Name:
Wesley Walter Anton Oliver

   1. Give an overview of your idea

Investigate the possibilities of improve network quality of realtime
communication, that required guaranties to ensure they get required
capacity, latency and through put. Evaluate all different routing protocols
or the ones that vodacom is using in its backbones and BS, such as OSFP,
PGP, BGP…
See if we can dynamically configure and change there ratio in which packet
traffic is interlaced over an aggregate pipeline. This would require
detecting ip and port combinations for different services, to greater
detail that Quality of Service in ip layer. Also require the ability to
dynamic change the ratio on detect and lookup of clients account. I am sure
so sick the terrible call quality and realtime video thought put of current
internet.

   1. What company strategy does your idea speak to and please explain?
   Your idea can speak to more than one strategy. (Cost Reduction, Revenue
   Growth and/or Improve NPS)

Higher quality network for realtime communications, more product diversity
and guaranties you provide to the customer and for him understand things
better.
In the long term, better planing of network capacity were it is required.
Opens door for different types of product offerings, that can differentiate
one self in the market to be the market leader.

   1. What do you believe is the 5-year value/ benefit of your idea to
   Vodacom? This can be revenue, cost saving, NPS points, etc.

revenue, ability to offer more diverse set of packages, cost saving(better
capacity planing capabilities), more reliability and simpler to diagnose
capacity complaints. Especially with tv going to require 100mbit lines for
like 16K video.

   1. What makes your idea innovative?

Simple fact that no is doing this and the industry, is well dragging its
feet when it comes to quality. Fact no will commit to providing guaranteed
capacity at this level aggregation isp end client. Everything else
typically best effort!! Be the first network to be able to truly provide
realtime communication guarantees above what current protocols that are
under development.

   1. Does the commercial implementation of your idea require coding?

Well I am sure, there are various script and configuration, and integration
to build out product across the whole network on a grand scale.

   1. Do you know if your idea will impact on any of Vodacom’s current
   systems? If so, how?

Hopefully no more shitting realtime communication and calls, with packet
jitter and delays.
When implemented, would improve the network quality and the types of
services as it slowly rolled out and testing across the network. Will
potentially require reconfiguration of Cisco routine equipment and some
other equipment, to higher and better standards that international
community seem to have done, as far as I am where of.

   1. Are you aware if your idea is currently on a roadmap within Vodacom,
   if yes please detail

No chance!! No internet gives a hoot, apart from the users about realtime
communication quality. Few people like to challenge way things are done to
be better.

   1. Detail your idea and outline how you will create a proto-type to
   demonstrate at the hackathon

Well this would require first know what backend system are doing, then go
about investigation current capabilities of the router os software, look
for a way to be able to write script and code, configure those device in
this way. If configure them in this way do a test of the configuration and
see it works, would require some client server communicate faking data.
Then next step is to see integrate dynamic configuration and auto detection
and lookup product reserved capacity from local cache server on BS site.
Start with the basics and then build on from there.
This would require building a test network for using their equipment over a
single simulated backbone pipeline in office, connection to simulating pc,
to confirm routing and interlacing.

   1. Please state why you think your idea should be chosen

Traditional, the internet been open, however, the data that is moving over
the networks today, now required guarantees for quality of the end service
that is provided to the end user.
Traditional we have all resisted this type of package creation, however, in
todays world we want guarantee, which mean, need to know from which
physically points in network, you are required to provide these guarantee.
I would not buy package for video stream, were you can’t guaranty me
quality of 16K picture, because why waist all the money on the tv in the
first place.

Opens up the market to provide more dynamic packages, that are better than
the current ones.
Improves ability to plan, because clients are now committing to a package
that offers them their desired quality.
Mainly so that we can disrupt the market with better quality offering of
services, open the doors open to many more applications in the future, that
other networks wills’t be able to provide, with out undergoing the same
changes. They will be on the back foot, trying to figure it all out, while
we be pushing the boundaries of quality for realtime data reliability in
the future.

Hi,

What are the limitations?

I was thinking of the ability to setup Cisco routing equipment, such that
it can better route the internet traffic over the network and achieve a
better overall realtime communication and reliability than we seem to
current have and Qos can provide!

There are different types of traffic, which can be categorised as follows:

1. Reserved Minimum capacity on a pipe(back bone link)
a. Smart T.V Video
-SD
-702HD
-1080HD
- QD
- 8K
-16K
b. Mobile Voice Calls
c. Radio Streaming service
d. Voip
e. Realtime Medical surgery

2. Non reserved is basically all remaining data traffic, that can
experience congestion and packet delays, and jitter,
In which will not affect there quality and performance of the server.

Look into the ability too dynamic setup routing and firewall policies for
the bgp and like osfp ideally that used
By Vodacom in there telecoms backend actually, relevant.

What one is looking to do is determine the ratio of the different reserve
capacity above, that the pipe only
A back ground stretch should be interacting packets on a most ideal
1,2,3,4,5,6 round robin from each point with queue data.
This would ensure that along as the realtime transmission of packets
remains under there reserve capacity per second
There will be no congestion and thus no delays or jitter or call break ups,
or killing anyone in a realtime operation.

What is need is for each route to be able to detect the different types of
streams and then lookup there connection account subscription information,
To determine what there reservations are, wether they paying for 5 mb
reservation or 50mbit reservation to respective services.

So detect source and category, look up the type of reservation required and
then
update the aggregation pipeline to capacity reservations total, while those
data packets are being sent and still detected.

Then also for each mobile call over it, also register and dynamic update
the ratios.

The remaining capacity on the line, can then be used for general data, that
doesn’t need realtime communication guarantees that avoid congestion!

So when there is less than the maximum reserver capacity on the line
currently being used, the rest can be used for data, which can then
Leed to the isp(vodacom) using it as burst data to provide better data
packages, with base 10mbits, with content ratio and share density of
20:1, like all isp back in the day used to do. Then other the ability to
burst to 100mbits or 1gigbits, if the back bones capacity for reservation
capacity is being under utalitzed, let the data category take advantage of
it.

One of the things is one also needs to look into detecting when
transmission of streaming packets has stopped, to dynamically reduce and
update the reserved capacity on the line.

In the long run, one needs a protocol to do this, so that for medical
operations, there is no detecting, its becomes more of registration process
to guaranty allay between source and destination that this reservation is
put in place.

The routing system is going to have notify both end immediately with super
high packet priority system, that reservation has broken down
Otherwise, realtime operations, could have few bag results, unless machine
can only move to position on packet being received and that distance of
change per packet can be warranty to be kept to 10000 of mm per position
packet.
We still need both parties to know that things going wrong asap, so take
preventative measure immediately.

Guess this would be the investigation into the backend routing equipment
and firewalls and tech that vodacom uses,
Such that we can see if we be able to configure device to operate in such a
way, if so see how far we can take it.

Ultimately it will change isp market to sell voice package reservation for
sd, HD + video provide to which they have mirror video server to warranty
streaming quality experience. Then sell separate traditional isp packages
for data with all there content ratio.

The whole industry is going to have to change in the long term.

Kind Regards,

Wesley Oliver

On Thu, Jul 4, 2019 at 9:05 AM Wesley Oliver <[email-masked]> wrote:

> 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,
> to inspect, allowing data in router queues, to be interlace differently,
> No longer FIFO, which would address buffer bloat.
>
> Video:50%, BandWidth reserver at client level, based on the subscription
> of 40Mbits dedicate reserved bandwidth to video server across the internet
> for them,
> Can forward hackathon suggestion to Vodacom too.. for the CISCO and
> dynamic pipe reservation for traffic on pipes..
>> - There a a few subtle HOL-blocking issues in porting the system to H3
>> due to the way streams work in QUIC
>> 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.
>>
>> 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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 4 Jul 2019 09:27:20 -0400

> and also on https://h3.edm.uhasselt.be.

Last paragraph of Section 5 states:

  " Note finally that our H3 implementation does employ
  " dynamic header compression using the QPACK specification.
  " While QPACK can in itself lead to HOL-blocking between
  " streams, even in the normal modus operandi (as decoding some
  " compressed headers can depend on the receipt of previously
  " encoded headers), we believe this effect is negligible in
  " our reported results.

I take this to mean that, in your experiment setup, the QPACK encoders
on both client and server use the dynamic table, that blocked streams
are allowed, and that the encoders do, in fact, risk blocked stream to
maximize compression performance.  Is that correct?

If so, did you observe HOL-blocking between encoder and request
streams?

It would be interesting to tease out the magnitude of this impact
by running experiments with QPACK_BLOCKED_STREAMS=0 vs
QPACK_BLOCKED_STREAMS=100 (since you already have a setup ready).
My own (purely theoretical) musings about this can be found here:

    https://blog.litespeedtech.com/2018/01/29/qcram-04-does-not-solve-head-of-line-blocking/

(QCRAM-04 became QPACK.)

I still posit that

  " the single control stream introduces ordering to otherwise
  " independent operations, making it unable to minimize HoLB
  " for a class of applications.

And that upgrading to HTTP/3 (from HTTP/1.x or HTTP/2) will make
some applications perform worse -- if blocked streams are allowed.

  - Dmitri.

---

From: Wesley Oliver <[email-masked]>
Date: Mon, 8 Jul 2019 15:07:32 +0200

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.

---

From: Robin MARX <[email-masked]>
Date: Mon, 8 Jul 2019 17:08:45 +0200

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 [email-masked], 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 <[email-masked]> wrote:

> 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
> 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.
>
> Typically when written a single instance of an application or internal to
> a microservice, we would have the following layers:
> Layers
> 1 DAL
> 3 BLL, Business Logic Layer (in which all complex exposed decision that
> all must consume)
> 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.
>
>
>> 1.2  This would allow for true real-time communication below QoS, that
>> the application can control, so for my gaming communication
>> One important thing to remember here is that there needs to be the
>> ability to dynamically change the priority of the flushing
>> 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..
>> 2. Http 3.0, where the server can flush async resource dynamically as
>> they become available.
>>
>> , then dynamic reserve that bandwidth, when detect connection being
>> opened in the video space.
>>
>> 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...
>> 4.2 Address congestion of upstream NAK and AK, using TMDA or somthing
>> more impressive, so that downstream bandwidth is not constrainted by a
>>> 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.
>>> 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
>>>  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
>>> - Are implementers willing to implement 2 completely different
>>> approaches (1 for H3, 1 for H2)?
>> LinkedIn:
>> https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/

-- 

Robin Marx

www.uhasselt.be

---

From: Nick Harper <[email-masked]>
Date: Mon, 8 Jul 2019 16:05:50 -0700

I'm in favor of a simpler approach for H3 priorities, and something like
Patrick Meenan's proposal sounds good. I like the simplicity and
statelessness of that proposal. I don't foresee any issues with
implementing it in Chrome, nor do I see any issues with needing to maintain
separate priority implementations for H2 vs H3.

I would prefer that a simpler proposal be the default (MTI) priority scheme
used in H3. If there are applications that need the full expressivity and
complexity of the H2 or draft-20 tree based approach to priorities, I think
that would be better suited to an extension.