standalone QUIC implementations

[Juan Batiz-Benet]

Hey list,

Can't. Wait. QUIC is so the right thing. I've been following for ... years? ... and can't wait to see QUIC used all over.

But it's a bit difficult at the moment. There's no lib, and only one lang implementation, and AFAICT no public roadmap for either?

I think that we should undertake a bit of effort to make it possible to be used more widely. IMO this means:

1. a standalone libquic with the sources extracted from chromium.

   (and make chromium use this lib -- otherwise main dev will continue in chromium tree and extraction will continue to be painful every time).

2. implementations in other languages.

   (there was mention of a Go impl. would love to see that, and we'd help build it).

But, before that can happen, has the spec reached sufficient correctness? 

Things should still move fast and change, but I think development will be helped by wider usage.

Thanks,

Juan

[Alyssa (Rzeszutek) Wilk]

Hey Juan,

You make a couple of great points, which coincidentally the QUIC team at Google was just discussing yesterday.  We've worked out enough of the kinks that  we're happy with QUIC's performance, and while there will probably be a couple more version bumps early next year (handling stateless rejects and HTTP2 for example) backwards compatibility will hopefully be less of an issue after that.  Given that, we're hoping to engage other developers and get real server implementations (apache, nginx etc.) in 2015.   We also definitely want to make sure the code is reusable by other projects using C++ or swigged wrappers.  Where SPDY was something fairly straight-forward to reimplement from scratch, crypto and congestion control are complicated enough there's more value in enabling a common QUIC code base, so there's work to be done there as well.  I don't think we're going to be able to spend Googler developer resources in native implementations in other languages in the next year, but if there's API refactors we can do to allow better (SWIG) code reuse in Go, for example, we'd be happy to help out there.

cheers,

Alyssa

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Gregory Burd]

Hey Juan,

You pinged me the other day via an issue on GitHub (https://github.com/gburd/quic/issues/2) about this.  A while back I started the process of creating a "libquic" by extracting the sources from the chromium sources (https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/&ct=rc&cd=1&q=quic&sq=package:chromium).  Plans changed and time passed without progress.  This is now on a long list of project that I've let languish the past two years.  Recently this has become interesting to me again, and I might get over the hump and find more time if there were a few collaborators working together.  If Google were to somehow bless it that would help propel the work forward even more quickly.

best,

-greg

[Juan Batiz-Benet]

Inlined below

Thanks for the quick response Alyssa! 

On Thu, Dec 11, 2014 at 7:13 AM, 'Alyssa (Rzeszutek) Wilk' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

Hey Juan,

You make a couple of great points, which coincidentally the QUIC team at Google was just discussing yesterday.  We've worked out enough of the kinks that  we're happy with QUIC's performance, and while there will probably be a couple more version bumps early next year (handling stateless rejects and HTTP2 for example) backwards compatibility will hopefully be less of an issue after that. 

Yeah, I think all that is fine to do across other implementations, particularly if there's one central library.

 

Given that, we're hoping to engage other developers and get real server implementations (apache, nginx etc.) in 2015.   We also definitely want to make sure the code is reusable by other projects using C++ or swigged wrappers. 

Tons of people will want to use QUIC as a transport for all kinds of servers, not just the main httpds. We, for example, want to use it in a p2p distributed filesystem.

 

Where SPDY was something fairly straight-forward to reimplement from scratch, crypto and congestion control are complicated enough there's more value in enabling a common QUIC code base, so there's work to be done there as well.

Yeah, i think getting a libquic and wrapping it is TRTTD for now.

 

  I don't think we're going to be able to spend Googler developer resources in native implementations in other languages in the next year, but if there's API refactors we can do to allow better (SWIG) code reuse in Go, for example, we'd be happy to help out there.

libquic would be enough to wrap + start writing servers in other languages. Once that's there, native implementations will follow.

I haven't looked in depth at the QUIC interface. I recently wrapped the c++ UDT implementation with cgo, so I can try this (realistically in Jan, or a weekend) and come back with api feedback / issues. The important thing for me is extracting the QUIC codebase to a standalone libquic repo. Is that something the team is thinking about doing? (ease of development is often a major limiting factor in developer adoption).

Another question: is QUIC compatible with WebRTC? I know WebRTC picks between TCP, UDP, SCTP/UDP, and other transports. is QUIC one of them?

Thanks again!

On Fri, Dec 12, 2014 at 6:24 PM, Gregory Burd <greg...@gmail.com> wrote:

Hey Juan,

You pinged me the other day via an issue on GitHub (https://github.com/gburd/quic/issues/2) about this.  A while back I started the process of creating a "libquic" by extracting the sources from the chromium sources (https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/&ct=rc&cd=1&q=quic&sq=package:chromium).  Plans changed and time passed without progress.  This is now on a long list of project that I've let languish the past two years.  Recently this has become interesting to me again, and I might get over the hump and find more time if there were a few collaborators working together.  If Google were to somehow bless it that would help propel the work forward even more quickly.

Happy to contribute. Let's see what route Alyssa et al recommend :)

Juan

 

[Alyssa (Rzeszutek) Wilk]

On Fri, Dec 12, 2014 at 9:42 PM, Juan Batiz-Benet <ju...@benet.ai> wrote:

Inlined below

Thanks for the quick response Alyssa! 

On Thu, Dec 11, 2014 at 7:13 AM, 'Alyssa (Rzeszutek) Wilk' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

Hey Juan,

You make a couple of great points, which coincidentally the QUIC team at Google was just discussing yesterday.  We've worked out enough of the kinks that  we're happy with QUIC's performance, and while there will probably be a couple more version bumps early next year (handling stateless rejects and HTTP2 for example) backwards compatibility will hopefully be less of an issue after that. 

Yeah, I think all that is fine to do across other implementations, particularly if there's one central library.

 

Given that, we're hoping to engage other developers and get real server implementations (apache, nginx etc.) in 2015.   We also definitely want to make sure the code is reusable by other projects using C++ or swigged wrappers. 

Tons of people will want to use QUIC as a transport for all kinds of servers, not just the main httpds. We, for example, want to use it in a p2p distributed filesystem.

 

Ah, nifty.  I'm very excited to see non-HTTP uses of QUIC.

 

Where SPDY was something fairly straight-forward to reimplement from scratch, crypto and congestion control are complicated enough there's more value in enabling a common QUIC code base, so there's work to be done there as well.

Yeah, i think getting a libquic and wrapping it is TRTTD for now.

 

Agreed - while we are interested in making the code more reusable, it's probably not happening in the next few months and I'd hate that to be a blocking point for anyone.

That said, if you find that having a built target which is a subset of the current chrome net library is useful, we could add in extra (scoped) targets sooner rather than later.

 

  I don't think we're going to be able to spend Googler developer resources in native implementations in other languages in the next year, but if there's API refactors we can do to allow better (SWIG) code reuse in Go, for example, we'd be happy to help out there.

libquic would be enough to wrap + start writing servers in other languages. Once that's there, native implementations will follow.

I haven't looked in depth at the QUIC interface. I recently wrapped the c++ UDT implementation with cgo, so I can try this (realistically in Jan, or a weekend) and come back with api feedback / issues. The important thing for me is extracting the QUIC codebase to a standalone libquic repo. Is that something the team is thinking about doing? (ease of development is often a major limiting factor in developer adoption).

Can you explain what you're hoping to get from a standalone repository?  Is it an easy to download library, or a source repository that's a bit easier to download and build than chrome?  

At some point I'd really like to see the latter, but pulling out the code is the easiest part.  Creating build files which work on multiple systems is a lot of work, and not breaking them is even more work.  We also have to resolve the issues with external dependencies (e.g. OpenSSL) and how to make sure we handle those well, cross-platform.    There's a reason the chrome build tools got so complicated :-P

I wonder if it'd be useful to start with something simple, like some scripts around the chrome checkout process to minimize the files pulled to actual dependencies, and then a thin library target, and move towards a full parallel repository as the group of people playing around with QUIC (and willing to help maintain such a repo) grows.  Any thoughts on this?

 

Another question: is QUIC compatible with WebRTC? I know WebRTC picks between TCP, UDP, SCTP/UDP, and other transports. is QUIC one of them?

Not today, but it's on our list :-)

 

Thanks again!

On Fri, Dec 12, 2014 at 6:24 PM, Gregory Burd <greg...@gmail.com> wrote:

Hey Juan,

You pinged me the other day via an issue on GitHub (https://github.com/gburd/quic/issues/2) about this.  A while back I started the process of creating a "libquic" by extracting the sources from the chromium sources (https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/&ct=rc&cd=1&q=quic&sq=package:chromium).  Plans changed and time passed without progress.  This is now on a long list of project that I've let languish the past two years.  Recently this has become interesting to me again, and I might get over the hump and find more time if there were a few collaborators working together.  If Google were to somehow bless it that would help propel the work forward even more quickly.

Happy to contribute. Let's see what route Alyssa et al recommend :)

Juan

 

--

[Juan Batiz-Benet]

Hello, 

On Mon, Dec 15, 2014 at 12:50 PM, 'Alyssa (Rzeszutek) Wilk' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

On Fri, Dec 12, 2014 at 9:42 PM, Juan Batiz-Benet <ju...@benet.ai> wrote:

Inlined below

Thanks for the quick response Alyssa! 

On Thu, Dec 11, 2014 at 7:13 AM, 'Alyssa (Rzeszutek) Wilk' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

Hey Juan,

You make a couple of great points, which coincidentally the QUIC team at Google was just discussing yesterday.  We've worked out enough of the kinks that  we're happy with QUIC's performance, and while there will probably be a couple more version bumps early next year (handling stateless rejects and HTTP2 for example) backwards compatibility will hopefully be less of an issue after that. 

Yeah, I think all that is fine to do across other implementations, particularly if there's one central library.

 

Given that, we're hoping to engage other developers and get real server implementations (apache, nginx etc.) in 2015.   We also definitely want to make sure the code is reusable by other projects using C++ or swigged wrappers. 

Tons of people will want to use QUIC as a transport for all kinds of servers, not just the main httpds. We, for example, want to use it in a p2p distributed filesystem.

 

Ah, nifty.  I'm very excited to see non-HTTP uses of QUIC.

 

Where SPDY was something fairly straight-forward to reimplement from scratch, crypto and congestion control are complicated enough there's more value in enabling a common QUIC code base, so there's work to be done there as well.

Yeah, i think getting a libquic and wrapping it is TRTTD for now.

 

Agreed - while we are interested in making the code more reusable, it's probably not happening in the next few months and I'd hate that to be a blocking point for anyone.

That said, if you find that having a built target which is a subset of the current chrome net library is useful, we could add in extra (scoped) targets sooner rather than later.

 

  I don't think we're going to be able to spend Googler developer resources in native implementations in other languages in the next year, but if there's API refactors we can do to allow better (SWIG) code reuse in Go, for example, we'd be happy to help out there.

libquic would be enough to wrap + start writing servers in other languages. Once that's there, native implementations will follow.

I haven't looked in depth at the QUIC interface. I recently wrapped the c++ UDT implementation with cgo, so I can try this (realistically in Jan, or a weekend) and come back with api feedback / issues. The important thing for me is extracting the QUIC codebase to a standalone libquic repo. Is that something the team is thinking about doing? (ease of development is often a major limiting factor in developer adoption).

Can you explain what you're hoping to get from a standalone repository?  Is it an easy to download library, or a source repository that's a bit easier to download and build than chrome?  

Both an easy to download library, and a source repo that's waaaaaaay easier to work with. Contribution depends on development friction, and right now it's very time consuming. Getting it down to something like

git clone github.com/<>/quic

cd quic

make

Would do wonders for development.

At some point I'd really like to see the latter, but pulling out the code is the easiest part.  Creating build files which work on multiple systems is a lot of work, and not breaking them is even more work.  We also have to resolve the issues with external dependencies (e.g. OpenSSL) and how to make sure we handle those well, cross-platform.    There's a reason the chrome build tools got so complicated :-P

Yeah. I understand the predicament very well...

I wonder if it'd be useful to start with something simple, like some scripts around the chrome checkout process to minimize the files pulled to actual dependencies, and then a thin library target, and move towards a full parallel repository as the group of people playing around with QUIC (and willing to help maintain such a repo) grows.  Any thoughts on this?

This sounds like TRTTD. I wonder-- actually-- if we could start by moving the code to a different repo but keep everything the same. i.e. have the chrome tools download it from a different endpoint (like the semi-recently separated webrtc lib). For now keep _all_ the build files/targets exactly the same so that no chrome people are affected. once that's there, together we can experiment and figure out what the build targets should look like, etc. Cheap branches + forks that remain close to mainline is key. (the reason for actually changing the endpoint and not just doing a code dump once is that codebases would likely diverge fast). Would this make sense for you?

 

Another question: is QUIC compatible with WebRTC? I know WebRTC picks between TCP, UDP, SCTP/UDP, and other transports. is QUIC one of them?

Not today, but it's on our list :-)

:) 

 

Thanks for all your hard work on this!! Please let me know how we can help.

Juan

 

Thanks again!

On Fri, Dec 12, 2014 at 6:24 PM, Gregory Burd <greg...@gmail.com> wrote:

Hey Juan,

You pinged me the other day via an issue on GitHub (https://github.com/gburd/quic/issues/2) about this.  A while back I started the process of creating a "libquic" by extracting the sources from the chromium sources (https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/&ct=rc&cd=1&q=quic&sq=package:chromium).  Plans changed and time passed without progress.  This is now on a long list of project that I've let languish the past two years.  Recently this has become interesting to me again, and I might get over the hump and find more time if there were a few collaborators working together.  If Google were to somehow bless it that would help propel the work forward even more quickly.

Happy to contribute. Let's see what route Alyssa et al recommend :)

Juan

 

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/proto-quic/ajV1Il3UoUg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to proto-quic+...@chromium.org.

[Gregory Burd]

Juan,

This is what I'm trying to work toward, a simple complete single repo which implements the QUIC protocol with a familiar drop-in API to ease adoption and speed up tuning/bug-fixing/etc.  I'm in the process  of merging in the latest sources from the Chromium project.  Then I'll work on a build system (yes, that's hard to do... I used to work on Berkeley DB's which was equally complex, it's simply a matter of effort/time) and a way to automate the process of finding and importing divergent changes from the Chromium repo (which should be the primary source for protocol development, this should not be a fork).  I envision it being used for HTTP as well as non-HTTP traffic, for instance my use case doesn't involve HTTP (it's bulk transport of data that should not impact the latency of active TCP connections).  I've also registered libquic.so/net as  a homebase for the project (quic.net/org are both taken).

-greg

[Jana Iyengar]

Hi Greg,

This is very exciting -- please do post your progress. We'd be keen to hear how your work goes.

- jana

[Peter Thatcher]

On Friday, December 12, 2014 at 6:43:01 PM UTC-8, Juan Benet wrote:

Inlined below

Thanks for the quick response Alyssa! 

On Thu, Dec 11, 2014 at 7:13 AM, 'Alyssa (Rzeszutek) Wilk' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

Hey Juan,

You make a couple of great points, which coincidentally the QUIC team at Google was just discussing yesterday.  We've worked out enough of the kinks that  we're happy with QUIC's performance, and while there will probably be a couple more version bumps early next year (handling stateless rejects and HTTP2 for example) backwards compatibility will hopefully be less of an issue after that. 

Yeah, I think all that is fine to do across other implementations, particularly if there's one central library.

 

Given that, we're hoping to engage other developers and get real server implementations (apache, nginx etc.) in 2015.   We also definitely want to make sure the code is reusable by other projects using C++ or swigged wrappers. 

Tons of people will want to use QUIC as a transport for all kinds of servers, not just the main httpds. We, for example, want to use it in a p2p distributed filesystem.

 

Where SPDY was something fairly straight-forward to reimplement from scratch, crypto and congestion control are complicated enough there's more value in enabling a common QUIC code base, so there's work to be done there as well.

Yeah, i think getting a libquic and wrapping it is TRTTD for now.

 

  I don't think we're going to be able to spend Googler developer resources in native implementations in other languages in the next year, but if there's API refactors we can do to allow better (SWIG) code reuse in Go, for example, we'd be happy to help out there.

libquic would be enough to wrap + start writing servers in other languages. Once that's there, native implementations will follow.

I haven't looked in depth at the QUIC interface. I recently wrapped the c++ UDT implementation with cgo, so I can try this (realistically in Jan, or a weekend) and come back with api feedback / issues. The important thing for me is extracting the QUIC codebase to a standalone libquic repo. Is that something the team is thinking about doing? (ease of development is often a major limiting factor in developer adoption).

Another question: is QUIC compatible with WebRTC? I know WebRTC picks between TCP, UDP, SCTP/UDP, and other transports. is QUIC one of them?

WebRTC team member here.

It depends on what you mean by "compatible.  It's not "compatible" in the sense that it's not part of any standard or deployment at the moment.  But it is "compatible" with WebRTC in the sense that we can theoretically use QUIC in WebRTC as a replacement for DTLS, SCTP, and perhaps more.

In fact, we've already started to experiment with QUIC in the WebRTC stack that goes into Chrome.  For example:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/p2p/quic/&q=webrtc%20quic&sq=package:chromium

Nothing usable or even demoable yet, but we're working on it.

[Juan Benet]

On Thu, Mar 17, 2016 at 2:46 PM 'Peter Thatcher' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

On Friday, December 12, 2014 at 6:43:01 PM UTC-8, Juan Benet wrote:

Inlined below

Thanks for the quick response Alyssa! 

On Thu, Dec 11, 2014 at 7:13 AM, 'Alyssa (Rzeszutek) Wilk' via QUIC Prototype Protocol Discussion group <proto...@chromium.org> wrote:

Hey Juan,

You make a couple of great points, which coincidentally the QUIC team at Google was just discussing yesterday.  We've worked out enough of the kinks that  we're happy with QUIC's performance, and while there will probably be a couple more version bumps early next year (handling stateless rejects and HTTP2 for example) backwards compatibility will hopefully be less of an issue after that. 

Yeah, I think all that is fine to do across other implementations, particularly if there's one central library.

 

Given that, we're hoping to engage other developers and get real server implementations (apache, nginx etc.) in 2015.   We also definitely want to make sure the code is reusable by other projects using C++ or swigged wrappers. 

Tons of people will want to use QUIC as a transport for all kinds of servers, not just the main httpds. We, for example, want to use it in a p2p distributed filesystem.

 

Where SPDY was something fairly straight-forward to reimplement from scratch, crypto and congestion control are complicated enough there's more value in enabling a common QUIC code base, so there's work to be done there as well.

Yeah, i think getting a libquic and wrapping it is TRTTD for now.

 

  I don't think we're going to be able to spend Googler developer resources in native implementations in other languages in the next year, but if there's API refactors we can do to allow better (SWIG) code reuse in Go, for example, we'd be happy to help out there.

libquic would be enough to wrap + start writing servers in other languages. Once that's there, native implementations will follow.

I haven't looked in depth at the QUIC interface. I recently wrapped the c++ UDT implementation with cgo, so I can try this (realistically in Jan, or a weekend) and come back with api feedback / issues. The important thing for me is extracting the QUIC codebase to a standalone libquic repo. Is that something the team is thinking about doing? (ease of development is often a major limiting factor in developer adoption).

Another question: is QUIC compatible with WebRTC? I know WebRTC picks between TCP, UDP, SCTP/UDP, and other transports. is QUIC one of them?

WebRTC team member here.

It depends on what you mean by "compatible.  It's not "compatible" in the sense that it's not part of any standard or deployment at the moment.  But it is "compatible" with WebRTC in the sense that we can theoretically use QUIC in WebRTC as a replacement for DTLS, SCTP, and perhaps more.

In fact, we've already started to experiment with QUIC in the WebRTC stack that goes into Chrome.  For example:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/p2p/quic/&q=webrtc%20quic&sq=package:chromium

Nothing usable or even demoable yet, but we're working on it.

That's great to hear! Looking fwd to what develops. :)

Thanks again!

On Fri, Dec 12, 2014 at 6:24 PM, Gregory Burd <greg...@gmail.com> wrote:

Hey Juan,

You pinged me the other day via an issue on GitHub (https://github.com/gburd/quic/issues/2) about this.  A while back I started the process of creating a "libquic" by extracting the sources from the chromium sources (https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/&ct=rc&cd=1&q=quic&sq=package:chromium).  Plans changed and time passed without progress.  This is now on a long list of project that I've let languish the past two years.  Recently this has become interesting to me again, and I might get over the hump and find more time if there were a few collaborators working together.  If Google were to somehow bless it that would help propel the work forward even more quickly.

Happy to contribute. Let's see what route Alyssa et al recommend :)

Juan

 

--
You received this message because you are subscribed to a topic in the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/proto-quic/ajV1Il3UoUg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to proto-quic+...@chromium.org.