Re: Inets http2 support

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Fred Hebert-2
On Mon, Nov 18, 2019 at 7:55 AM josh zinny <[hidden email]> wrote:
Hi guys,

I was wondering if http2/3 is one the roadmap for Inets? I know there's is Cowboy and Gun.
However, I'm interested in the Inets httpd(http2). I have read the Erlang 22.1 documentation, but it only references http/1.1.

Also, any suggestions on how to achieve this or a workaround will be greatly appreciated.


I do not know about the OTP team's plans with regards to supporting HTTP/2, but I can say this: HTTP/2 is sufficiently complex and different from HTTP/1.1 that it's not just a workaround to add support to it; it essentially asks people to reimplement something reminiscent of SCTP over TCP in order to provide multiple channels, and includes things like reimplementing the sliding window mechanisms that exist within individual TCP connections. The workaround to "wanting to use HTTP/2" is "use an HTTP/2 library"; it's too complex to just add rapidly. If not Cowboy and Gun, then something like Chatterbox can be an acceptable library, and if these do not work, then using some sort of HTTP2-to-HTTP1 proxy, which some service providers in the cloud can do for you, generally.

Regards,
Fred.
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Jesper Louis Andersen-2
On Mon, Nov 18, 2019 at 2:56 PM Fred Hebert <[hidden email]> wrote:
I do not know about the OTP team's plans with regards to supporting HTTP/2, but I can say this: HTTP/2 is sufficiently complex and different from HTTP/1.1 that it's not just a workaround to add support to it; it essentially asks people to reimplement something reminiscent of SCTP over TCP in order to provide multiple channels, and includes things like reimplementing the sliding window mechanisms that exist within individual TCP connections. The workaround to "wanting to use HTTP/2" is "use an HTTP/2 library"; it's too complex to just add rapidly. If not Cowboy and Gun, then something like Chatterbox can be an acceptable library, and if these do not work, then using some sort of HTTP2-to-HTTP1 proxy, which some service providers in the cloud can do for you, generally.


And HTTP/3 requires you to implement a dialect of QUIC on top of UDP. That is, you "just" have to write a complete TCP-like protocol and get it to run fast. The complexity of this is through the roof. In principle, this effort should have been modular, so you have a chance to catch up, but alas, no. I'm not sure I like the direction this is going in, because the resource investment is so heavy. Mind you, last time such a thing happened we had XML and then Douglas Crockford comes by with a hack. The hack then won, despite all its flaws.

Another important point is that when you start deploying new protocols next to TCP, or alter TCPs congestion control system, you risk seriously damaging the internet. There is a recent paper (from CMU I think) which argues that TCP-BBR is bad for the TCP flows in many situations.

--
J.
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Loïc Hoguin-3
On 19/11/2019 17:16, Jesper Louis Andersen wrote:

> On Mon, Nov 18, 2019 at 2:56 PM Fred Hebert <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I do not know about the OTP team's plans with regards to supporting
>     HTTP/2, but I can say this: HTTP/2 is sufficiently complex and
>     different from HTTP/1.1 that it's not just a workaround to add
>     support to it; it essentially asks people to reimplement something
>     reminiscent of SCTP over TCP in order to provide multiple channels,
>     and includes things like reimplementing the sliding window
>     mechanisms that exist within individual TCP connections. The
>     workaround to "wanting to use HTTP/2" is "use an HTTP/2 library";
>     it's too complex to just add rapidly. If not Cowboy and Gun, then
>     something like Chatterbox can be an acceptable library, and if these
>     do not work, then using some sort of HTTP2-to-HTTP1 proxy, which
>     some service providers in the cloud can do for you, generally.
>
>
> And HTTP/3 requires you to implement a dialect of QUIC on top of UDP.
> That is, you "just" have to write a complete TCP-like protocol and get
> it to run fast. The complexity of this is through the roof. In
> principle, this effort should have been modular, so you have a chance to
> catch up, but alas, no. I'm not sure I like the direction this is going
> in, because the resource investment is so heavy. Mind you, last time
> such a thing happened we had XML and then Douglas Crockford comes by
> with a hack. The hack then won, despite all its flaws.

I'm afraid there isn't going to be a hack for this one. No need to take
on the entire complexity all at once though.

I've contemplated starting work on a QUIC implementation but I've queued
it back to second place so I might only start in 6 months if nobody does
before me. I would go at it in this order:

* Implement QPACK (easy and more or less independent)

* Write the NIF for the QUIC state machine (shortcut! for example the
CloudFlare implementation)

* Write the network layer. The hard part is TLS 1.3 (including 0-RTT!),
but it can be skipped by using a custom cleartext "encryption" mechanism
so you can still progress even if you don't have TLS 1.3 yet. Since it's
being worked on, waiting is good!

* Implement HTTP/3

* Use TLS 1.3

* Get rid of the NIF

For the network layer you're never going to have good performance with
the current gen_udp interface. You pretty much have to go with socket.

Then there's priorities. The good news there is that you can implement
them for HTTP/2 first (if the draft is adopted, that is):
https://tools.ietf.org/html/draft-kazuho-httpbis-priority-04

I think a "not so bad" full-Erlang implementation is entirely possible
by the end of 2020, not too long after the protocol becomes a standard.
Then there's the very long optimization step.

As to whether an Erlang implementation would perform well enough
compared to C, that's another question entirely. But it's on risk I'd be
willing to take.

Cheers,

--
Loïc Hoguin
https://ninenines.eu
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Lukas Larsson-8
On Thu, Nov 21, 2019 at 4:17 PM Loïc Hoguin <[hidden email]> wrote:
I've contemplated starting work on a QUIC implementation but I've queued
it back to second place so I might only start in 6 months if nobody does
before me.

We have also considered doing this. I've already written a nif wrapper for the CloudFlare rust code that can do the very basics, however the steps from basic to fully-fledged implementation seems huge. Also, from what I understand, the cloud flare implementation is not ready for production use, but that will hopefully change in the future.

So far my impression has been more similar to what Jesper describes. It will be a lot of work to get correct and fast enough in Erlang. Using some other stack (like the mvfst for instance) would cut out a lot of the complexity, but we lose all of the control of what is going on. Though I suppose that is the same as what happens with TCP today.

I've been changing opinion on every other week for a while whether I think it would be a good idea for us to implement it or not, this week I'm against :) The things that I think make this job huge is the flow control, congestion control things and the constant changes to the protocol that seem to be planned. However, if there are more people than us at the OTP team that are interested in helping out to build good support for QUIC, it becomes a lot more interesting.

One of the use-cases (besides the obvious HTTP/3 use-case) that we have been thinking about would be to allow the Erlang distribution to run over QUIC.
 
* Write the network layer. The hard part is TLS 1.3 (including 0-RTT!), 
but it can be skipped by using a custom cleartext "encryption" mechanism
so you can still progress even if you don't have TLS 1.3 yet. Since it's
being worked on, waiting is good!

We were thinking about re-using the ssl applications TLS 1.3 implementation. It is not trivial as transport and TLS are upsidedown for QUIC, but should be doable sais Ingela and Peter :p

Lukas
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Loïc Hoguin-3
Mind you I also change my mind on the complexity every other week...
Ultimately it's just something that has to be done so it doesn't really
matter how big the task is. Gotta get started first. From what I've seen
of the progress June 2020 or so would be a good time to start as the
protocol should be close to completion by then.

On 21/11/2019 17:22, Lukas Larsson wrote:
> One of the use-cases (besides the obvious HTTP/3 use-case) that we have
> been thinking about would be to allow the Erlang distribution to run
> over QUIC.

That's what I want for RabbitMQ and based on experiments emulating some
aspects of QUIC, this is an insanely promising prospect. I expect QUIC
to triple the throughput for mirrored RabbitMQ queues *at the very least*.

Some aspects of the distribution do not play well with QUIC though, like
`monitor(process, {Name, Node})`. This is the one thing in the
distribution protocol for which you can't guarantee ordering over
multiple QUIC streams because you don't have the pid that you have for
all other messages. Right now you also must parse the message in order
to figure out on which stream you have to send it, it would probably be
better to have this info readily available. Of course you could always
use a single QUIC channel but then what's the point. :-)

> We were thinking about re-using the ssl applications TLS 1.3
> implementation. It is not trivial as transport and TLS are upsidedown
> for QUIC, but should be doable sais Ingela and Peter :p

If we can have a good interface that has TLS return the
encrypted/decrypted binary data rather than write it directly to the
socket, I could also use it in Gun to support TLS connections over TLS
proxies. Right now it uses the callback module and while it works it's
fairly complex.

--
Loïc Hoguin
https://ninenines.eu
Reply | Threaded
Open this post in threaded view
|

Re: QUIC was Inets http2 support

Lukas Larsson-8


On Thu, 21 Nov 2019, 17:50 Loïc Hoguin, <[hidden email]> wrote:
Mind you I also change my mind on the complexity every other week...
Ultimately it's just something that has to be done so it doesn't really
matter how big the task is.

Indeed. The question  however is if it is best to do it like we've done for crypto or for ssl/ssh. 

Gotta get started first. From what I've seen
of the progress June 2020 or so would be a good time to start as the
protocol should be close to completion by then.

I don't think it is too bad an idea to start now either. From what I can tell the rfc:s are pretty stable already.


On 21/11/2019 17:22, Lukas Larsson wrote:
> One of the use-cases (besides the obvious HTTP/3 use-case) that we have
> been thinking about would be to allow the Erlang distribution to run
> over QUIC.

That's what I want for RabbitMQ and based on experiments emulating some
aspects of QUIC, this is an insanely promising prospect. I expect QUIC
to triple the throughput for mirrored RabbitMQ queues *at the very least*.

Do you? Why? What aspect of it do you think would do that?


Some aspects of the distribution do not play well with QUIC though, like
`monitor(process, {Name, Node})`. This is the one thing in the
distribution protocol for which you can't guarantee ordering over
multiple QUIC streams because you don't have the pid that you have for
all other messages.

Hmm, yes. Not trivial to solve but should be doable.

Right now you also must parse the message in order
to figure out on which stream you have to send it, it would probably be
better to have this info readily available.

Fixing this should be very simple. The information is there we just need to put it in the tuple returned.

Of course you could always
use a single QUIC channel but then what's the point. :-)

> We were thinking about re-using the ssl applications TLS 1.3
> implementation. It is not trivial as transport and TLS are upsidedown
> for QUIC, but should be doable sais Ingela and Peter :p

If we can have a good interface that has TLS return the
encrypted/decrypted binary data rather than write it directly to the
socket, I could also use it in Gun to support TLS connections over TLS
proxies. Right now it uses the callback module and while it works it's
fairly complex.

Maybe this would be a good starting point for us. Building an API that makes this possible.


--
Loïc Hoguin
https://ninenines.eu
Reply | Threaded
Open this post in threaded view
|

Re: QUIC was Inets http2 support

Loïc Hoguin-3
On 21/11/2019 18:21, Lukas Larsson wrote:
> I don't think it is too bad an idea to start now either. From what I can
> tell the rfc:s are pretty stable already.

The QUIC ones yes, minus the priority mechanism. But HTTP/3 depends on
both priorities being figured out and also the pushed mechanism. I'm not
sure how far the latter got or if it's going to be supported at all
initially. So for my use case it's not as stable as it could be.

>     On 21/11/2019 17:22, Lukas Larsson wrote:
>      > One of the use-cases (besides the obvious HTTP/3 use-case) that
>     we have
>      > been thinking about would be to allow the Erlang distribution to run
>      > over QUIC.
>
>     That's what I want for RabbitMQ and based on experiments emulating some
>     aspects of QUIC, this is an insanely promising prospect. I expect QUIC
>     to triple the throughput for mirrored RabbitMQ queues *at the very
>     least*.
>
>
> Do you? Why? What aspect of it do you think would do that?

I said too much. :-)

>     Some aspects of the distribution do not play well with QUIC though,
>     like
>     `monitor(process, {Name, Node})`. This is the one thing in the
>     distribution protocol for which you can't guarantee ordering over
>     multiple QUIC streams because you don't have the pid that you have for
>     all other messages.
>
>
> Hmm, yes. Not trivial to solve but should be doable.

My current solution is "don't use it". rpc:call(whereis) plus monitor is
almost the same as well.

>     Right now you also must parse the message in order
>     to figure out on which stream you have to send it, it would probably be
>     better to have this info readily available.
>
>
> Fixing this should be very simple. The information is there we just need
> to put it in the tuple returned.

I'd love to have this today. :-)

>     Of course you could always
>     use a single QUIC channel but then what's the point. :-)
>
>      > We were thinking about re-using the ssl applications TLS 1.3
>      > implementation. It is not trivial as transport and TLS are
>     upsidedown
>      > for QUIC, but should be doable sais Ingela and Peter :p
>
>     If we can have a good interface that has TLS return the
>     encrypted/decrypted binary data rather than write it directly to the
>     socket, I could also use it in Gun to support TLS connections over TLS
>     proxies. Right now it uses the callback module and while it works it's
>     fairly complex.
>
>
> Maybe this would be a good starting point for us. Building an API that
> makes this possible.

So much to do so little time. :-)

--
Loïc Hoguin
https://ninenines.eu
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Ingela Andin
In reply to this post by Fred Hebert-2

Hi!

Regarding  the roadmap for inets. The first goal is to strip a lot legacy stuff from inets, to make it easier to maintain. We think that
its use case should be small embedded uses and there are other webservices for those who want all the belles and whistles. 

But as others have pointed out there is no quick fix for HTTP/2 or HTTP/3.  At the moment fully supported TLS-1.3 is our priority.
And also other underlaying features protocols will have to come first.

Regards Ingela Erlang/OTP team - Ericsson AB


Den mån 18 nov. 2019 kl 13:56 skrev josh zinny <[hidden email]>:
Hi guys,

I was wondering if http2/3 is one the roadmap for Inets? I know there's is Cowboy and Gun.
However, I'm interested in the Inets httpd(http2). I have read the Erlang 22.1 documentation, but it only references http/1.1.

Also, any suggestions on how to achieve this or a workaround will be greatly appreciated.

Many thanks,
Josh

Reply | Threaded
Open this post in threaded view
|

Re: QUIC was Inets http2 support

Lukas Larsson-8
In reply to this post by Loïc Hoguin-3


On Thu, 21 Nov 2019, 19:00 Loïc Hoguin, <[hidden email]> wrote:
On 21/11/2019 18:21, Lukas Larsson wrote:
> I don't think it is too bad an idea to start now either. From what I can
> tell the rfc:s are pretty stable already.

The QUIC ones yes, minus the priority mechanism. But HTTP/3 depends on
both priorities being figured out and also the pushed mechanism. I'm not
sure how far the latter got or if it's going to be supported at all
initially. So for my use case it's not as stable as it could be.

Ah yes, I've not been following those at all as they don't matter for the distribution case. 


>     On 21/11/2019 17:22, Lukas Larsson wrote:
>      > One of the use-cases (besides the obvious HTTP/3 use-case) that
>     we have
>      > been thinking about would be to allow the Erlang distribution to run
>      > over QUIC.
>
>     That's what I want for RabbitMQ and based on experiments emulating some
>     aspects of QUIC, this is an insanely promising prospect. I expect QUIC
>     to triple the throughput for mirrored RabbitMQ queues *at the very
>     least*.
>
>
> Do you? Why? What aspect of it do you think would do that?

I said too much. :-)

>     Some aspects of the distribution do not play well with QUIC though,
>     like
>     `monitor(process, {Name, Node})`. This is the one thing in the
>     distribution protocol for which you can't guarantee ordering over
>     multiple QUIC streams because you don't have the pid that you have for
>     all other messages.
>
>
> Hmm, yes. Not trivial to solve but should be doable.

My current solution is "don't use it". rpc:call(whereis) plus monitor is
almost the same as well.

Mhm, it is rare enough that using some slow fall back would work.

>     Right now you also must parse the message in order
>     to figure out on which stream you have to send it, it would probably be
>     better to have this info readily available.
>
>
> Fixing this should be very simple. The information is there we just need
> to put it in the tuple returned.

I'd love to have this today. :-)

I'll see what we can do.


>     Of course you could always
>     use a single QUIC channel but then what's the point. :-)
>
>      > We were thinking about re-using the ssl applications TLS 1.3
>      > implementation. It is not trivial as transport and TLS are
>     upsidedown
>      > for QUIC, but should be doable sais Ingela and Peter :p
>
>     If we can have a good interface that has TLS return the
>     encrypted/decrypted binary data rather than write it directly to the
>     socket, I could also use it in Gun to support TLS connections over TLS
>     proxies. Right now it uses the callback module and while it works it's
>     fairly complex.
>
>
> Maybe this would be a good starting point for us. Building an API that
> makes this possible.

So much to do so little time. :-)

Indeed.


--
Loïc Hoguin
https://ninenines.eu
Reply | Threaded
Open this post in threaded view
|

Re: QUIC was Inets http2 support

Ingela Andin
In reply to this post by Loïc Hoguin-3

Hi!


>
>      > We were thinking about re-using the ssl applications TLS 1.3
>      > implementation. It is not trivial as transport and TLS are
>     upsidedown
>      > for QUIC, but should be doable sais Ingela and Peter :p
>

I think it is doable. I think the big job is implementing the QUIC state machine.
But maybe we need a QUIC flavoured TLS state machine that reuses much of the
same code. Similar to that we have a TLS statemachine, a TLS-1.3 statmachine  and 
DTLS statemachine at the moment. 
 

>     If we can have a good interface that has TLS return the
>     encrypted/decrypted binary data rather than write it directly to the
>     socket, I could also use it in Gun to support TLS connections over TLS
>     proxies. Right now it uses the callback module and while it works it's
>     fairly complex.
>  
> Maybe this would be a good starting point for us. Building an API that
> makes this possible.


We can think about it. This will probably not do it for QUIC as it wants to
handle the encryption part itself. But I think there are many places where can make
possible new APIs. 
 

So much to do so little time. :-)


Like always, but I do not think QUIC will replace TCP and day soon...  I think the trick is to find
small steps. 

Regards Ingela Erlang/OTP team - Ericsson AB


 
--
Loïc Hoguin
https://ninenines.eu
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Dave Cottlehuber-5
In reply to this post by Loïc Hoguin-3
On Thu, 21 Nov 2019, at 16:50, Loïc Hoguin wrote:

> Mind you I also change my mind on the complexity every other week...
> Ultimately it's just something that has to be done so it doesn't really
> matter how big the task is. Gotta get started first. From what I've seen
> of the progress June 2020 or so would be a good time to start as the
> protocol should be close to completion by then.
>
> On 21/11/2019 17:22, Lukas Larsson wrote:
> > One of the use-cases (besides the obvious HTTP/3 use-case) that we have
> > been thinking about would be to allow the Erlang distribution to run
> > over QUIC.

Had you considered something like nng instead of HTTP/3 for this?

- already available[1]
- much much simpler than HTTP/3/QUIC (I would hate to count the lines of code)
- the survey pattern[2] looks ideal for maintaining heartbeats

I've fiddled with enm[3] https://github.com/basho/enm which is wire compatible,
and it's very fast indeed.

[1]: https://github.com/nanomsg/nng
[2]: https://nanomsg.org/gettingstarted/nng/survey.html
[3]: https://github.com/basho/enm
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Loïc Hoguin-3
On 22/11/2019 21:03, Dave Cottlehuber wrote:
>> On 21/11/2019 17:22, Lukas Larsson wrote:
>>> One of the use-cases (besides the obvious HTTP/3 use-case) that we have
>>> been thinking about would be to allow the Erlang distribution to run
>>> over QUIC.
>
> Had you considered something like nng instead of HTTP/3 for this?

You mean QUIC, no need for HTTP/3 for the distribution.

> - already available[1]
> - much much simpler than HTTP/3/QUIC (I would hate to count the lines of code)
> - the survey pattern[2] looks ideal for maintaining heartbeats
>
> I've fiddled with enm[3] https://github.com/basho/enm which is wire compatible,
> and it's very fast indeed.
>
> [1]: https://github.com/nanomsg/nng
> [2]: https://nanomsg.org/gettingstarted/nng/survey.html
> [3]: https://github.com/basho/enm

 From what I understand it's still built on top of TCP. The main
advantage of QUIC is that you can map messages onto different streams.
Each stream's messages are ordered but the whole connection is not.
Streams don't block each other. Different streams may have different
priorities (we could have a process_flag that indicates this for very
important processes and the distribution driver would send their
messages before others).

Cheers,

--
Loïc Hoguin
https://ninenines.eu
Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

PAILLEAU Eric

QUIC :

"To solve this problem, QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes."


Wow... Nice security issues in perspective!



Envoyé depuis mon mobile



---- Loïc Hoguin a écrit ----

On 22/11/2019 21:03, Dave Cottlehuber wrote:

>> On 21/11/2019 17:22, Lukas Larsson wrote:

>>> One of the use-cases (besides the obvious HTTP/3 use-case) that we have

>>> been thinking about would be to allow the Erlang distribution to run

>>> over QUIC.

>

> Had you considered something like nng instead of HTTP/3 for this?



You mean QUIC, no need for HTTP/3 for the distribution.



> - already available[1]

> - much much simpler than HTTP/3/QUIC (I would hate to count the lines of code)

> - the survey pattern[2] looks ideal for maintaining heartbeats

>

> I've fiddled with enm[3] https://github.com/basho/enm which is wire compatible,

> and it's very fast indeed.

>

> [1]: https://github.com/nanomsg/nng

> [2]: https://nanomsg.org/gettingstarted/nng/survey.html

> [3]: https://github.com/basho/enm



From what I understand it's still built on top of TCP. The main

advantage of QUIC is that you can map messages onto different streams.

Each stream's messages are ordered but the whole connection is not.

Streams don't block each other. Different streams may have different

priorities (we could have a process_flag that indicates this for very

important processes and the distribution driver would send their

messages before others).



Cheers,



--

Loïc Hoguin

https://ninenines.eu

Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Adam Lindberg-7
@Eric: It can have upsides for Erlang distribution as well (security considerations aside). For example, quick reconnection in case of net splits and changing network environments (e.g. cloud servers getting new IPs because of some network issue). Perhaps even the possibility to mask some network issues that would tear down a TCP connection. Or just roaming Erlang nodes on mobile devices :-D

@Lukas, @Loïc: Working on QUIC separately would still be beneficial though, right? Or is there something in HTTP/3 that requires tighter integration with QUIC that a separate implementation would not provide?

Cheers,
Adam

> On 23. Nov 2019, at 13:38, Eric Pailleau <[hidden email]> wrote:
>
> QUIC :
> "To solve this problem, QUIC includes a connection identifier which uniquely identifies the connection to the server regardless of source. This allows the connection to be re-established simply by sending a packet, which always contains this ID, as the original connection ID will still be valid even if the user's IP address changes."
>
> Wow... Nice security issues in perspective!
>
>
> Envoyé depuis mon mobile
>
>
> ---- Loïc Hoguin a écrit ----
>
> On 22/11/2019 21:03, Dave Cottlehuber wrote:
>
> >> On 21/11/2019 17:22, Lukas Larsson wrote:
>
> >>> One of the use-cases (besides the obvious HTTP/3 use-case) that we have
>
> >>> been thinking about would be to allow the Erlang distribution to run
>
> >>> over QUIC.
>
> >
>
> > Had you considered something like nng instead of HTTP/3 for this?
>
>
>
> You mean QUIC, no need for HTTP/3 for the distribution.
>
>
>
> > - already available[1]
>
> > - much much simpler than HTTP/3/QUIC (I would hate to count the lines of code)
>
> > - the survey pattern[2] looks ideal for maintaining heartbeats
>
> >
>
> > I've fiddled with enm[3] https://github.com/basho/enm which is wire compatible,
>
> > and it's very fast indeed.
>
> >
>
> > [1]: https://github.com/nanomsg/nng
>
> > [2]: https://nanomsg.org/gettingstarted/nng/survey.html
>
> > [3]: https://github.com/basho/enm
>
>
>
> From what I understand it's still built on top of TCP. The main
>
> advantage of QUIC is that you can map messages onto different streams.
>
> Each stream's messages are ordered but the whole connection is not.
>
> Streams don't block each other. Different streams may have different
>
> priorities (we could have a process_flag that indicates this for very
>
> important processes and the distribution driver would send their
>
> messages before others).
>
>
>
> Cheers,
>
>
>
> --
>
> Loïc Hoguin
>
> https://ninenines.eu
>

Reply | Threaded
Open this post in threaded view
|

Re: Inets http2 support

Loïc Hoguin-3
On 26/11/2019 10:39, Adam Lindberg wrote:
> @Lukas, @Loïc: Working on QUIC separately would still be beneficial though, right? Or is there something in HTTP/3 that requires tighter integration with QUIC that a separate implementation would not provide?

I am definitely talking about separate implementations, QUIC could be in
OTP or third party and HTTP/3 would just sit in Cowboy/Cowlib.

What HTTP/3 would provide to QUIC development is a use case that uses
most of the features from QUIC and would allow optimizing QUIC. I'm
thinking for example of the synchronization part of QPACK, of the
different types of streams QUIC is using, and so on.

I don't think HTTP/3 would have a significant impact on the features of
the QUIC library though. There might be an exception to that, and that's
currently an unknown due to the lack of consensus, and that is the
priority mechanism. It's arguably more into optimization territory as
well though.

So yes it's fine to work on them separately. I just think about the full
picture since I'm mostly interested in HTTP myself. If I started working
on this today I would focus on getting the HTTP/3 part before QUIC
because I'm more interested, not because of any coupling between the two.

Cheers,

--
Loïc Hoguin
https://ninenines.eu