[Bloat] Fwd: [proto-quic] QUIC library "libquic" and Go binding

[Bloat] Fwd: [proto-quic] QUIC library "libquic" and Go binding

[Dave Taht]

happy. Now we can benchmark quic in netperf-wrapper.


---------- Forwarded message ----------
From: Brian Hong <sungjinhong@devsisters.com>
Date: Mon, Mar 16, 2015 at 12:34 AM
Subject: [proto-quic] QUIC library "libquic" and Go binding
To: proto-quic@chromium.org


Hello QUIC team,

Me and my colleague have been working on creating a working QUIC Go binding.
Since QUIC is a transport layer, we have also tried to create a socket-like APIs
along with HTTP QUIC server/client support.

# libquic

In order to do this work, we needed to seperate QUIC code from Chromium
codebase. The result: https://github.com/devsisters/libquic
It is a minimally patched QUIC code extracted from Chromium codebase.

From the library programmers perspective, QUIC code has many unneeded/unused
dependencies. Manually looking for the unneeded dependencies are very tedious.
We have managed to do this anyway and created simple scripts to make syncing
from the upstream Chromium codebase easy as possible.

There have been many patches to utilitity classes and functions. Most of them
are `#if 0` macro patches. They remove unused functions from QUIC. Some patches
actually replace existing functions to remove third-party library dependencies.

All the needed patches are in the repository directory:
[patch](https://github.com/devsisters/libquic/tree/master/patch)

We replaced two components. Class `base::debug::BreakDebugger` and utility
component `url/base/net_util.cc`. The replaced `BreakDebugger` does absolutely
nothing. Replaced `net_util.cc` file removes dependencies to `url/url_parse.h`
which requires Mozilla URL parsing library. Since the functions required by QUIC
were simple, We have reimplemented needed functions with no external dependency.

All the replaced components are in the directory:
[custom](https://github.com/devsisters/libquic/blob/master/custom/)

The result is that the only required dependency is BoringSSL. We have not been
able to replace this with OpenSSL since the functions used by QUIC only exist in
BoringSSL.

# goquic/gospdyquic

This is a work-in-progress QUIC implementation for Go. And is in a *highly
experimental* status. There is some problems when the library is under high
concurrency. We plan to debug this problem, and when we feel certain that the
problem might be from the underlying upstream codebase, we plan to issue it here
too.

The link to the project: https://github.com/devsisters/goquic

There is also gospdyquic: https://github.com/devsisters/gospdyquic

This adds QUIC support to existing Go HTTP server framework. The basic gist is
that you can create QUIC client and servers very easily. See the examples:

  * https://github.com/devsisters/gospdyquic/blob/master/example/client.go
  * https://github.com/devsisters/gospdyquic/blob/master/example/server.go
  * https://github.com/devsisters/gospdyquic/blob/master/example/reverse_proxy.go

# quicbench

Using gospdyquic, we modified existing `gobench` program to benchmark QUIC
servers: https://github.com/devsisters/quicbench

# Preliminary benchmark results

Here are some preliminary benchmark results. Details are in the `goquic` site.

| Payload Size | Requests per Second |
| ------------ | ------------------: |
| 30 B         | 23832.18            |
| 1 kB         | 21704.84            |
| 5 kB         | 9343.58             |
| 10 kB        | 5312.75             |


On 10kB case, calculating the total network throughput is `435Mbps`.

Connection performance results are `2905.58 CPS`.

Details: https://github.com/devsisters/goquic#preliminary-benchmarks

# Conclusion

We hope that our work would help QUIC ecosystem prosper. We've also licensed
our code with same 3-clause BSD license from Chromium. We don't intent to fork
from Chromium project. The code will be frequently synced from upstream. The
syncing process itself is also designed to be effortless as possible.

(see: https://github.com/devsisters/libquic#syncing-from-upstream )

Also, one more thing. :) If Chromium team would somehow 'bless' our project,
it would be very great. Let's find ways to collaborate.

Thank you for reading this. Contact me for any questions regarding this project.

Best regards,
Sung-jin Brian Hong

--
Sung-jin (Brian) Hong
Senior Technical Lead
Devsisters Corp.
+82-2-544-2950 (Work)
+82-2-544-3625 (Fax)
+82-10-6247-8846 (Mobile)

CONFIDENTIALITY. This communication is intended only for the use of
the intended recipient(s) and may contain information that is
privileged and confidential.  If you are not the intended recipient,
please note that any dissemination of this communication is
prohibited.  If you have received this communication in error, please
erase all copies of the message, including all attachments, and please
also notify the sender immediately.  Thank you for your cooperation.

--
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+unsubscribe@chromium.org.
To post to this group, send email to proto-quic@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.


-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb