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

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