DCV on the head node leverages the default transport protocol configuration of WebSockets over TCP, but it can support QUIC with minor backwards-compatible configuration change.
I enable QUIC by default as my users are up to 300msec from our preferred Parallel Cluster region and experience significant latency, jitter & packet loss, which are far more tolerable using QUIC.
Regardless, given the performance improvements, I think the project should consider enabling QUIC by default, but at the very least make it optional, given that the worst-case outcome is any network or client issues when attempting QUIC simply result in graceful fallback to the existing TCP-based connections.
One complication is that QUIC is only supported using the DCV thick client, not via web browser.
Proposed changes required:
Set enable-quic-frontend=true in /etc/dcv/dcv.conf
Add UDP/ from in the head node security group
Update pcluster dcv-connect to test for & launch the thick client after fetching session credentials
DCV on the head node leverages the default transport protocol configuration of WebSockets over TCP, but it can support QUIC with minor backwards-compatible configuration change.
I enable QUIC by default as my users are up to 300msec from our preferred Parallel Cluster region and experience significant latency, jitter & packet loss, which are far more tolerable using QUIC.
Regardless, given the performance improvements, I think the project should consider enabling QUIC by default, but at the very least make it optional, given that the worst-case outcome is any network or client issues when attempting QUIC simply result in graceful fallback to the existing TCP-based connections.
One complication is that QUIC is only supported using the DCV thick client, not via web browser.
Proposed changes required:
enable-quic-frontend=true
in /etc/dcv/dcv.confpcluster dcv-connect
to test for & launch the thick client after fetching session credentials