Deprecating gQUIC support

[jogme]

Is there a reason for keeping the Google QUIC implementation in the code or could it be already deprecated?

The documentation page says:

gQUIC Google QUIC. The original lsquic supported only Google QUIC. gQUIC is going to become obsolete. (Hopefully soon).

[litespeedtech]

I think some users still use gQUIC instead of IETF QUIC.
And it has to be done in a major version, and it is considerable amount of efforts.
On the other hand, a code base for IETF QUIC only can be more efficient and cleaner.

[jogme]

In that case conditional build with enable-gquic could gap the need to provide gquic support and would also help to move forward from it. Would that be a possibility you could work with?

[litespeedtech]

That's OK, I think it introduces more work, as we need to keep both with/without gquic support work properly whenever changing the code. :-)

[dtikhonov]

@jogme is the presence of gQUIC support causing you issues? I am curious to learn what they are.

[litespeedtech]

I guess it is just the extra efforts for porting to OpenSSL. :-)

[dtikhonov]

Having lsquic support OpenSSL would be a Good Thing (TM). I think, as the middle ground, we could keep gQUIC support and support OpenSSL simply by compiling out gQUIC when OpenSSL is configured.

I wonder how much gQUIC is still used. There must be people still measuring this -- there used to be a few years back when the protocol was in active development.

[jogme]

@dtikhonov Thank you for reaching out! gQUIC is obsoleted and should be present only on legacy machines as said at [0].
Therefore there is no point on putting more work into that protocol and giving it openssl support. If you have any data about usage, please share; I could not find anything recent.

[0] -https://peering.google.com/#/learn-more/quic

[dtikhonov]

If you deprecate gQUIC in the OpenSSL PR, we'll take it.

Let me know if you have questions regarding any place in the code.

[jogme]

Unfortunately I have no capacity to work on this.

[sbranden]

If you deprecate gQUIC in the OpenSSL PR, we'll take it.

Let me know if you have questions regarding any place in the code.

So if anyone has patches to remove gQUIC from the code you are willing to take them? By remove, I mean remove, not just put in a compile option.

[dtikhonov]

Yes -- provided that it's a side-effect of OpenSSL support, which would come in the same PR.

[sbranden]

Yes -- provided that it's a side-effect of OpenSSL support, which would come in the same PR.

I created a new issue for this instead:
#580

GQUIC removal can be done without openSSL changes and has many additional benefits in doing so.

[dtikhonov]

Moving this conversation back to the original thread. @sbranden writes:

A lot of work has gone into supporting GQUIC over the years but it is deprecated. Keeping technical debt in the lsquic repo increases maintenance issues as well creating unnecessary problems integrating new features. There are also numerous configuration options and variables in the library that are only necessary with GQUIC creating additional burden when using the library. GQUIC code should be removed from lsquic mainline in order to simplify the codebase and allow for easier maintenance and development going forward.

Code stability is the main reason we have kept GQUIC in the code base:

The two QUIC versions, GQUIC and IETF QUIC, have lived side by side in this codebase for about 7-8 years. Taking one out, while -- yes -- making the code simpler to maintain going forward, introduces a risk of regression. OpenSSL support is a tradeoff we are willing to take, but just removing GQUIC for its own sake is a much weaker argument to make. To us, the code is stable, been stable, and those who don't want to use the GQUIC protocol can turn it off.