mirror of
https://github.com/mollyim/webrtc.git
synced 2025-05-19 16:47:50 +01:00
0ca62e3752
dcSCTP seems to be able to provoke usrsctp to send ABORT in some situations, as described in https://github.com/sctplab/usrsctp/issues/597. Using a packetdrill script, it seems as a contributing factor to this behavior is when a FORWARD-TSN chunk is bundled with a DATA chunk. This is a valid and recommended pattern in RFC3758: "F2) The data sender SHOULD always attempt to bundle an outgoing FORWARD TSN with outbound DATA chunks for efficiency." However, that seems to be a rare event in usrsctp, which generally sends each FORWARD-TSN in a separate packet. By doing the same, the assumption is that this scenario will generally be avoided. With many browsers and other clients using usrsctp, and which will not be upgraded for a long time, there is an advantage of avoiding the issue even if it is according to specification. Before this change, a FORWARD-TSN was bundled with outgoing DATA and due to this, it wasn't rate limited as the overhead was very little. With this change, a rate limiting behavior has been added to avoid sending too many FORWARD-TSN in small packets. It will be sent every RTT, or 200 ms, whichever is smallest. This is also described in the RFC. Bug: webrtc:12961 Change-Id: I3d8036a34f999f405958982534bfa0e99e330da3 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229101 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34801} |
||
|---|---|---|
| .. | ||
| common | ||
| fuzzers | ||
| packet | ||
| public | ||
| rx | ||
| socket | ||
| testing | ||
| timer | ||
| tx | ||
| BUILD.gn | ||
| OWNERS | ||