DTLS application data packets sometimes exceed MTU significantly
Categories
(Core :: WebRTC: Networking, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | fixed |
People
(Reporter: lgrahl, Assigned: lgrahl)
References
Details
Attachments
(2 files)
Every now and then, when sending a lot of data via a data channel, a DTLS packet of size ~16 KiB is being sent on the wire which obviously goes beyond the typically acceptable MTU.
This breaks interop with libwebrtc/Chrome which seems not to be able to handle DTLS application data packets of that size (it logs "short DTLS read. flushing" - probably just doesn't read all of it). In such a case, libwebrtc/Chrome closes the DTLS transport. I'd imagine interop isn't the main problem here though since it shouldn't send packets greater than the MTU anyway.
|
Assignee | |
Comment 1•5 years ago
|
||
CCing Michael since this could actually be a usrsctp issue, potentially handing out very large SCTP packets. Have you seen anything like that before?
|
||
Comment 2•5 years ago
|
||
Related to MTU issues, I'm only aware of https://github.com/sctplab/usrsctp/issues/410. But responsiveness is not good.
Do you have a way to reproduce this? Maybe one could connect two machines with an MTU of 9000 bytes and configure in usrsctp a smaller MTU. Then one could observe if one sees larger packets... Haven't done this yet.
|
|
Assignee | |
Comment 3•5 years ago
|
||
It's quite rare (sometimes happens in a session after ~10 mins while permanently sending large files) and I haven't found a reliable way to reproduce it. I'll try to extract the SCTP packets and will send you a trace if it turns out that there are very large SCTP packets in them.
Also, I'm not sure what usrsctp commit Firefox currently builds on. Might be worth bumping.
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 4•5 years ago
•
|
||
Alright, I can somewhat reliably reproduce this and it's definitely an issue for large data transfer. It does look like the large packet is indeed coming from usrsctp and all I need to do to trigger it is send as much data to fill the buffer of the remote peer. In our case, the remote peer (the Threema app) is uploading data elsewhere in a blocking manner which will therefore completely stall the flow of incoming data. Michael, I will send you a packet trace and Firefox log in private since this may contain sensitive information (even though I've done this on a test device).
|
|
||
Comment 5•5 years ago
|
||
OK, I see. It is definitely a problem in usrsctp. Are you using the latest usrsctp sources? Can you reproduce that with a simpler application than Firefox? Like with you webrtc implementation or with usrsctp only? That would simplify things...
|
|
Assignee | |
Comment 6•5 years ago
|
||
I've bumped to master (ea345b6d0c8a0f8701cf49445dba5ec8d34e2305) and that resolved the issue for me. So, it looks like this was a usrsctp issue. I'll provide a patch.
|
|
Assignee | |
Comment 7•5 years ago
|
||
|
|
Assignee | |
Comment 8•5 years ago
|
||
Nils, can you suggest an appropriate reviewer? :)
|
|
Assignee | |
Comment 9•5 years ago
|
||
|
|
Assignee | |
Comment 10•5 years ago
|
||
My assessment on severity is this: Even though it's not very easy to reproduce, it's consistently reproducible when transferring 10-50 MiB to a remote peer who is having a worse network connectivity than the sender. IMO, this makes it very severe for any application that is heavily relying on data channel transmission.
|
|
||
Comment 12•5 years ago
|
||
Nils is out until next week. I'd suggest bwc as a reviewer.
|
||
Comment 13•5 years ago
|
||
|
|
||
Comment 14•5 years ago
|
||
|
|
||
Comment 15•5 years ago
|
||
|
||
Updated•5 years ago
|
|
||
Comment 16•5 years ago
|
||
The try runs in comment 13 - 15 don't look green enough. Byron could you try to help Lennart getting these resolved?
|
|
||
Comment 17•5 years ago
|
||
(In reply to Nils Ohlmeier [:drno] from comment #16)
The try runs in comment 13 - 15 don't look green enough. Byron could you try to help Lennart getting these resolved?
That's bug 1649855, so not something we need to worry about here. The wpt can be found in comment 14. There are lots of oranges in comment 15, but those look like known intermittents on tests that do not involve DataChannels. I would say that try looks ok.
|
|
||
Comment 18•5 years ago
|
||
Lennart, anything else you need to do before I land this?
|
|
Assignee | |
Comment 19•5 years ago
|
||
Should be good to go.
Once https://github.com/sctplab/usrsctp/pull/417 is resolved/merged, we should bump again.
|
||
Comment 20•5 years ago
|
||
|
||
Comment 21•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/006350f1e363
https://hg.mozilla.org/mozilla-central/rev/79f69bdc105a
Description
•