Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update WebRTC message size limit #628

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Update WebRTC message size limit #628

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions webrtc/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -88,9 +88,9 @@ QUIC. The libp2p WebRTC message framing is not concerned with flow-control and
thus does not need the `RESET_STREAM` frame to be send in reply to a
`STOP_SENDING` frame.

Encoded messages including their length prefix MUST NOT exceed 16kiB to support
all major browsers. See ["Understanding message size
limits"](https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels#understanding_message_size_limits).
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).
Comment on lines +91 to +93
Copy link
Member

@lidel lidel Sep 5, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Implementations MAY choose to send smaller messages, e.g. to reduce delays
sending _flagged_ messages.
Comment on lines 94 to 95
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we account for forwards compatibility with future implementations that aren't arbitrarily limited like browsers currently?

Suggested change
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.


Expand Down