Able to reproduce this issue on reported version 62.0.3202.94 adn on latest canary 65.0.3286.0 using Mac 10.13.1, Ubuntu 14.04 and Windows 10 with steps mentioned in comment#0.

Bisect Info:
============
Good Build:62.0.3176.0 
Bad Build:62.0.3177.0

You are probably looking for a change made after 491911 (known good), but no later than 491912 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/352663bd89784d7161ad2bc832448ca38234c1d0..0b5aa967f47d7c575feaeafe2527e9051112f60c

Reviewed-on: https://chromium-review.googlesource.com/601051

Suspecting same from changelog.

@hans: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks!

The bisect points to a roll of usrsctp, which I'm not familiar with (I just rolled it as I was fixing a compiler warning).

I think someone on the WebRtc side needs to take a look at this.

perkj, perhaps?

I tried to build chromium my self, and did a bisect, based on:

  * 9382098 - Incrementing VERSION to 62.0.3202.93
  * 9f0d702 - Revert "Roll src/third_party/usrsctp/usrsctplib/ 2f6478eb8..f4819e1b1 (49 commits)"

And fiddle the revision of usrsctp in DEPS and third_party/usrsctp/README.chromium

The last good commit is ee6c99ef04e9e355d726513df666524c56e020e6
The first bad commit is be5e3e78227a58ccf137677ff46564c37fec66a8
> Author: Michael Tuexen <tuexen@fh-muenster.de>
> Date:   Wed Jul 19 14:44:48 2017 +0200
>
>     Sync with sctp-idata.

Hope these would help.

sctp is the engine used for data channels so the bisect is likely correct. 
deadbeef- is this something your team is working with? (I am no longer working with Chrome) 

Adding Michael Tuexen to the CC list. He might know something.

It seems 8cabcdc2844ff77a54a0bfcb172c2a96c5ae686f (Roll usrsctp f4819e1 -> 0e07626) fixes this issue. However, running the test file print this message multiple time:

> [1:17:1213/164900.065396:ERROR:sctptransport.cc(899)] SctpTransport->OnPacketFromSctpToNetwork(...): SCTP seems to have made a packet that is bigger than its official MTU: 1212 vs max of 1200


In usrsctp revision:
a7360a1e2bfb47039f52f7231b85c91da6c7e619 fixes the case "chunkSize >= 99077"
4f7f419c9fe3f531d0529a9209b2f4f52c645f70 fixes the case "chunkSize = 65665; totalSize = chunkSize * 2;

It looks like this was fixed here: https://github.com/sctplab/usrsctp/commit/4f7f419c9fe3f531d0529a9209b2f4f52c645f70

Yes, I guess the MTU problem was fixed by the commit referenced by deadbeef@webrtc.org

two things that seem to need doing:

- submit a test that tickles the problem (seems like it could be in web-platform-tests)
- roll usrsctp

who takes care of these?

I just ran the test on Canary (65.0.3294.3), and "Completed" was shown correctly on both cases.

The attached path adds two tests in third_party/WebKit/LayoutTests/external/wpt/webrtc/RTCDataChannel-send.html to re-produce this issue.

But:
1. Setting arbitrary size in the test case does not feel right. After reading [Understanding_message_size_limits], maybe I should set the size to 256kib?

[Understanding_message_size_limits]: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels#Understanding_message_size_limits

2. The second test case (sending two consecutive messages, each having 65665 bytes) specifically test the regression of usrsctp, which would not be found in the spec.

I have not taken time to figure out how to sumbit a change properly. Just my two cents here after fiddling the code.

Hope these help. BTW, the 'roll usrsctp' part is aready done in 8cabcdc2844ff77a54a0bfcb172c2a96c5ae686f as mentioned in Comment 7.

Deleted: add-test-datachannel-send.patch 2.3 KB

add-test-datachannel-send.patch 2.3 KB Download

You might consider updating adapter. The current adapter version will raise an exception in case the message is too large. And the maximum message size can be determined by `peerConnection.sctp.maxMessageSize`.

Seems like the main problem was fixed and with some follow-up work remaining (#8-10). Hence changing prio to 2.