Update WebRTC message size limit #628
Conversation
The browser bugs that made a 16KiB message size limit necessary have long been fixed. Increase the max size to 256KiB which has been verified experimentally between Firefox/Chrome and update the link to the Mozilla blog entry that discusses the limit and the relevant WebRTC issue that enables 256KiB messsages.
| Implementations MAY choose to send smaller messages, e.g. to reduce delays | ||
| sending _flagged_ messages. |
There was a problem hiding this comment.
Should we account for forwards compatibility with future implementations that aren't arbitrarily limited like browsers currently?
| Implementations MAY choose to send smaller messages, e.g. to reduce delays | |
| sending _flagged_ messages. | |
| Implementations MAY choose to send smaller messages, e.g. to reduce delays | |
| sending _flagged_ messages, and they MAY choose to accept larger messages | |
| to allow for forwards compatibility with more capable implementations in the | |
| future. |
A "be liberal in what you accept, conservative in what you emit" sort of thing.
| Encoded messages including their length prefix MUST NOT exceed 256kiB to support | ||
| all major browsers. See ["Large Data Channel Messages"](https://blog.mozilla.org/webrtc/large-data-channel-messages/) | ||
| and [WebRTC#40644524](https://issues.webrtc.org/issues/40644524). |
There was a problem hiding this comment.
Based on internal discussions, I believe we've decided to keep it at 16KiB to remain compatible with Kubo 0.30.0.
@achingbrain what is the next step here? figure out next steps without breaking interop? (e.g. how to negotiate higher size limit per connection via something like RTCSctpTransport/maxMessageSize?)
There was a problem hiding this comment.
I’m doing some experiments in the test plans repo to validate that we do in fact see a throughput increase with larger messages.
Marking this as a draft pending the outcome of that.
|
I'm curious, what was the conclusion with this PR and the potential throughput increase? |
|
The result was a roughly 15-25% speed increase when going from 16KB to 265KB chunks. See "Throughput" at the bottom of this page: https://observablehq.com/@libp2p-workspace/performance-dashboard?branch=feat%2Fadd-circuit-relay#branch I think this is still worth doing but we need the go/rust implementations to accept larger chunks - I think rust-libp2p will still reject them. |
|
Here's the draft pr @sukunrt created for go-libp2p: libp2p/go-libp2p#2949 Is everyone agreed that we want to increase the message size? If so, we can proceed with merging the go & rust pr |
The browser bugs that made a 16KiB message size limit necessary have long been fixed.
Increase the max size to 256KiB which has been verified experimentally between Firefox/Chrome and update the link to the Mozilla blog entry that discusses the limit and the relevant WebRTC issue that enables 256KiB messages.
Implementation status