[BUG-230617] New HTTP/3 Protocol for Second Life

[sl-service-account]

How would you like the feature to work?

It's would be using an Quick UDP Internet Connections Instead an TCP. QUIC is a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP) This Protocol will fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2's multiplexing is not visible to TCP's loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was impacted by the lost packet. Because QUIC provides native multiplexing, lost packets only impact the streams where data has been lost.

Why is this feature important to you? How would it benefit the community?

It's not an Obsolete UDP way. But It's new UDP Way that called Quick UDP Internet Connections which improves performance of connection-oriented web applications that are currently using TCP. As well to improve an Asset Fetching,Texture Loading,Baking and more.

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-230617 | | Summary | New HTTP/3 Protocol for Second Life | | Type | New Feature Request | | Priority | Unset | | Status | Accepted | | Resolution | Unresolved | | Created at | 2021-04-25T06:22:09Z | | Updated at | 2021-05-05T17:47:02Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2021-04-27T17:59:25.475-0500', 'How would you like the feature to work?': 'It\'s would be using an Quick UDP Internet Connections Instead an TCP. QUIC is a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP) This Protocol will fix a major problem of HTTP/2 called "head-of-line blocking": because the parallel nature of HTTP/2\'s multiplexing is not visible to TCP\'s loss recovery mechanisms, a lost or reordered packet causes all active transactions to experience a stall regardless of whether that transaction was impacted by the lost packet. Because QUIC provides native multiplexing, lost packets only impact the streams where data has been lost. ', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': "It's not an Obsolete UDP way. But It's new UDP Way that called Quick UDP Internet Connections which improves performance of connection-oriented web applications that are currently using TCP. As well to improve an Asset Fetching,Texture Loading,Baking and more.", } ```

[sl-service-account]

Rathgrith027 commented at 2021-04-27T22:59:25Z, updated at 2021-04-27T23:00:00Z

Anuk, the HTTP/3 standard hasn't even left the drafting phase yet. Give it a couple of years once it's matured and submit this again.

[sl-service-account]

Monty Linden commented at 2021-04-28T18:05:45Z, updated at 2021-04-29T23:26:04Z

As to head-of-line problems....  We've actually done work relative to this.  The HTTP system in the viewer has a classification scheme which allows large requests to be distinguished from small so that the HOL problem is reduced even for HTTP/1 (or even HTTP/0.9).  You can read more in the viewer codebase in https://bitbucket.org/lindenlab/viewer/src/master/indra/llcorehttp/README.Linden (from 2014).

Support for /2 and /3 is, of course, interesting.  But if you are seeing actual problems due to what you believe are HOL issues, that might be worth a defect-type Jira on its own.