The minimum RTO time shouldn't be lower than the delayed ack timeout
of the peer to avoid sending retransmissions before the peer has
actually intended to reply.
In usrsctp, the default delayed ack timeout is 200ms and configurable
using the `sctp_delayed_sack_time_default` option. In dcsctp, it's
min(RTO/2, 200ms), to avoid this issue.
Bug: webrtc:12614
Change-Id: Ie84c331334af660d66b1a7d90d20f5cf7e2a5103
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219100
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34026}
Due to a limit socket send buffer, it's quite easy to fill it up when
using exponential slow start, which results in dropping a lot of packets
and having to retransmit those.
Disabling this, to align it to how SCTP normally behaves, and then try
to stabilize it later. With SCTP slow start, it will increase with one
MTU for each RTT when there is no packet loss. Even this mode will
experience packet loss, but not as much will be lost, and it will
stabilize quicker.
Bug: webrtc:12614
Change-Id: Ibc484b19b7e708fe5bd837bbef178a2f69b7211f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218203
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33969}
This completes the basic implementation of the dcSCTP library. There
are a few remaining commits to e.g. add compatibility tests and
benchmarks, as well as more support for e.g. RFC8260, but those are not
strictly vital for evaluation of the library.
The Socket contains the connection establishment and teardown sequences
as well as the general chunk dispatcher.
Bug: webrtc:12614
Change-Id: I313b6c8f4accc144e3bb88ddba22269ebb8eb3cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214342
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33890}
The socket can measure the round-trip-time (RTT) by two different
scenarios:
* When a sent data is ACKed
* When a HEARTBEAT has been sent, which as been ACKed.
The RTT will be used to calculate which timeout value that should be
used for e.g. the retransmission timer (T3-RTX). On connections with a
low RTT, the RTO value will be low, and on a connection with high RTT,
the RTO value will be high. And on a connection with a generally low
RTT value, but where it varies a lot, the RTO value will be calculated
to be fairly high, to not fire unnecessarily. So jitter is bad, and is
part of the calculation.
Bug: webrtc:12614
Change-Id: I64905ad566d5032d0428cd84143a9397355bbe9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214045
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33832}
Clients will use this API for all their interactions with this library.
It's made into an interface (of which there will only be a single
implementation) simply for documentation purposes. But that also allows
clients to mock the library if wanted or to have a thread-safe wrapper,
as the library itself is not thread-safe, while keeping the same
interface.
Bug: webrtc:12614
Change-Id: I346af9916e26487da040c01825c2547aa7a5d0b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213348
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33648}
