2021-04-07 08:57:28 +02:00
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2021 The WebRTC project authors. All Rights Reserved.
|
|
|
|
|
*
|
|
|
|
|
* Use of this source code is governed by a BSD-style license
|
|
|
|
|
* that can be found in the LICENSE file in the root of the source
|
|
|
|
|
* tree. An additional intellectual property rights grant can be found
|
|
|
|
|
* in the file PATENTS. All contributing project authors may
|
|
|
|
|
* be found in the AUTHORS file in the root of the source tree.
|
|
|
|
|
*/
|
|
|
|
|
#include "net/dcsctp/socket/transmission_control_block.h"
|
|
|
|
|
|
|
|
|
|
#include <algorithm>
|
|
|
|
|
#include <cstdint>
|
|
|
|
|
#include <memory>
|
|
|
|
|
#include <string>
|
|
|
|
|
#include <utility>
|
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
|
|
#include "absl/types/optional.h"
|
|
|
|
|
#include "net/dcsctp/packet/chunk/data_chunk.h"
|
|
|
|
|
#include "net/dcsctp/packet/chunk/forward_tsn_chunk.h"
|
|
|
|
|
#include "net/dcsctp/packet/chunk/idata_chunk.h"
|
|
|
|
|
#include "net/dcsctp/packet/chunk/iforward_tsn_chunk.h"
|
|
|
|
|
#include "net/dcsctp/packet/chunk/reconfig_chunk.h"
|
|
|
|
|
#include "net/dcsctp/packet/chunk/sack_chunk.h"
|
|
|
|
|
#include "net/dcsctp/packet/sctp_packet.h"
|
|
|
|
|
#include "net/dcsctp/public/dcsctp_options.h"
|
|
|
|
|
#include "net/dcsctp/rx/data_tracker.h"
|
|
|
|
|
#include "net/dcsctp/rx/reassembly_queue.h"
|
|
|
|
|
#include "net/dcsctp/socket/capabilities.h"
|
|
|
|
|
#include "net/dcsctp/socket/stream_reset_handler.h"
|
|
|
|
|
#include "net/dcsctp/timer/timer.h"
|
|
|
|
|
#include "net/dcsctp/tx/retransmission_queue.h"
|
|
|
|
|
#include "net/dcsctp/tx/retransmission_timeout.h"
|
|
|
|
|
#include "rtc_base/logging.h"
|
|
|
|
|
#include "rtc_base/strings/string_builder.h"
|
|
|
|
|
|
|
|
|
|
namespace dcsctp {
|
|
|
|
|
|
2022-06-27 20:35:37 +00:00
|
|
|
TransmissionControlBlock::TransmissionControlBlock(
|
|
|
|
|
TimerManager& timer_manager,
|
|
|
|
|
absl::string_view log_prefix,
|
|
|
|
|
const DcSctpOptions& options,
|
|
|
|
|
const Capabilities& capabilities,
|
|
|
|
|
DcSctpSocketCallbacks& callbacks,
|
|
|
|
|
SendQueue& send_queue,
|
|
|
|
|
VerificationTag my_verification_tag,
|
|
|
|
|
TSN my_initial_tsn,
|
|
|
|
|
VerificationTag peer_verification_tag,
|
|
|
|
|
TSN peer_initial_tsn,
|
|
|
|
|
size_t a_rwnd,
|
|
|
|
|
TieTag tie_tag,
|
|
|
|
|
PacketSender& packet_sender,
|
|
|
|
|
std::function<bool()> is_connection_established)
|
|
|
|
|
: log_prefix_(log_prefix),
|
|
|
|
|
options_(options),
|
|
|
|
|
timer_manager_(timer_manager),
|
|
|
|
|
capabilities_(capabilities),
|
|
|
|
|
callbacks_(callbacks),
|
|
|
|
|
t3_rtx_(timer_manager_.CreateTimer(
|
|
|
|
|
"t3-rtx",
|
|
|
|
|
absl::bind_front(&TransmissionControlBlock::OnRtxTimerExpiry, this),
|
|
|
|
|
TimerOptions(options.rto_initial,
|
|
|
|
|
TimerBackoffAlgorithm::kExponential,
|
|
|
|
|
/*max_restarts=*/absl::nullopt,
|
|
|
|
|
options.max_timer_backoff_duration))),
|
|
|
|
|
delayed_ack_timer_(timer_manager_.CreateTimer(
|
|
|
|
|
"delayed-ack",
|
|
|
|
|
absl::bind_front(&TransmissionControlBlock::OnDelayedAckTimerExpiry,
|
|
|
|
|
this),
|
|
|
|
|
TimerOptions(options.delayed_ack_max_timeout,
|
|
|
|
|
TimerBackoffAlgorithm::kExponential,
|
|
|
|
|
/*max_restarts=*/0,
|
|
|
|
|
/*max_backoff_duration=*/absl::nullopt,
|
|
|
|
|
webrtc::TaskQueueBase::DelayPrecision::kHigh))),
|
|
|
|
|
my_verification_tag_(my_verification_tag),
|
|
|
|
|
my_initial_tsn_(my_initial_tsn),
|
|
|
|
|
peer_verification_tag_(peer_verification_tag),
|
|
|
|
|
peer_initial_tsn_(peer_initial_tsn),
|
|
|
|
|
tie_tag_(tie_tag),
|
|
|
|
|
is_connection_established_(std::move(is_connection_established)),
|
|
|
|
|
packet_sender_(packet_sender),
|
|
|
|
|
rto_(options),
|
|
|
|
|
tx_error_counter_(log_prefix, options),
|
|
|
|
|
data_tracker_(log_prefix, delayed_ack_timer_.get(), peer_initial_tsn),
|
|
|
|
|
reassembly_queue_(log_prefix,
|
|
|
|
|
peer_initial_tsn,
|
|
|
|
|
options.max_receiver_window_buffer_size,
|
|
|
|
|
capabilities.message_interleaving),
|
|
|
|
|
retransmission_queue_(
|
|
|
|
|
log_prefix,
|
|
|
|
|
my_initial_tsn,
|
|
|
|
|
a_rwnd,
|
|
|
|
|
send_queue,
|
|
|
|
|
absl::bind_front(&TransmissionControlBlock::ObserveRTT, this),
|
|
|
|
|
[this]() { tx_error_counter_.Clear(); },
|
|
|
|
|
*t3_rtx_,
|
|
|
|
|
options,
|
|
|
|
|
capabilities.partial_reliability,
|
|
|
|
|
capabilities.message_interleaving),
|
|
|
|
|
stream_reset_handler_(log_prefix,
|
|
|
|
|
this,
|
|
|
|
|
&timer_manager,
|
|
|
|
|
&data_tracker_,
|
|
|
|
|
&reassembly_queue_,
|
|
|
|
|
&retransmission_queue_),
|
|
|
|
|
heartbeat_handler_(log_prefix, options, this, &timer_manager_) {
|
|
|
|
|
send_queue.EnableMessageInterleaving(capabilities.message_interleaving);
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-07 08:57:28 +02:00
|
|
|
void TransmissionControlBlock::ObserveRTT(DurationMs rtt) {
|
|
|
|
|
DurationMs prev_rto = rto_.rto();
|
|
|
|
|
rto_.ObserveRTT(rtt);
|
|
|
|
|
RTC_DLOG(LS_VERBOSE) << log_prefix_ << "new rtt=" << *rtt
|
|
|
|
|
<< ", srtt=" << *rto_.srtt() << ", rto=" << *rto_.rto()
|
|
|
|
|
<< " (" << *prev_rto << ")";
|
|
|
|
|
t3_rtx_->set_duration(rto_.rto());
|
|
|
|
|
|
|
|
|
|
DurationMs delayed_ack_tmo =
|
|
|
|
|
std::min(rto_.rto() * 0.5, options_.delayed_ack_max_timeout);
|
|
|
|
|
delayed_ack_timer_->set_duration(delayed_ack_tmo);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
absl::optional<DurationMs> TransmissionControlBlock::OnRtxTimerExpiry() {
|
2021-05-05 16:22:29 +02:00
|
|
|
TimeMs now = callbacks_.TimeMillis();
|
2021-04-07 08:57:28 +02:00
|
|
|
RTC_DLOG(LS_INFO) << log_prefix_ << "Timer " << t3_rtx_->name()
|
|
|
|
|
<< " has expired";
|
dcsctp: Don't sent more packets before COOKIE ACK
While in the COOKIE ECHO state, there is a TCB and there might be data
in the send buffer, and RFC4960 allows the COOKIE ECHO chunk to bundle
additional DATA chunks in the same packet, but there mustn't be more
than one such packet sent, and that packet must have a COOKIE ECHO chunk
as the first chunk in it.
When the COOKIE ACK chunk has been received, the socket is allowed to
send multiple packets.
Previously, this was state managed by the socket and not the TCB, as
the socket is responsible for moving between the different states. And
when the COOKIE ECHO chunk was sent, the TCB was instructed to only send
a single packet by the socket.
However, if there were retransmissions or anything else that could
result in calling TransmissionControlBlock::SendBufferedChunks, it would
do as instructed and send those, even if the socket was in a state where
that wasn't allowed.
When the peer was dcSCTP, this didn't cause any issues as dcSCTP tries
to be tolerant in what it receives (but strict in what it sends, except
for when there are bugs). When the peer was usrsctp, it would send an
ABORT for each received packet that didn't have a COOKIE ECHO as the
first chunk, and then restart the handshake (sending an INIT). So this
resulted in a longer handshake, but the connection would eventually be
correctly established and any DATA chunks that resulted in the ABORTs
would've been retransmitted.
By making the TCB aware of that particular state, and to make it
responsible for creating the SCTP packet with the COOKIE ECHO chunk
first, and also to only send a single packet when it is in that state,
there will not be any way to bypass this limitation.
Also, while not explicitly mentioned in the RFC, the retransmission
timer will not affect resending any outstanding DATA chunks that were
bundled together with the COOKIE ECHO chunk, as then there would be two
timers that both would drive resending COOKIE ECHO and DATA chunks.
Bug: webrtc:12880
Change-Id: I76f215a03cceab5bafe9f16eb4775f3dc68a6f05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222645
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34329}
2021-06-16 12:52:42 +02:00
|
|
|
if (cookie_echo_chunk_.has_value()) {
|
|
|
|
|
// In the COOKIE_ECHO state, let the T1-COOKIE timer trigger
|
|
|
|
|
// retransmissions, to avoid having two timers doing that.
|
|
|
|
|
RTC_DLOG(LS_VERBOSE) << "Not retransmitting as T1-cookie is active.";
|
|
|
|
|
} else {
|
|
|
|
|
if (IncrementTxErrorCounter("t3-rtx expired")) {
|
|
|
|
|
retransmission_queue_.HandleT3RtxTimerExpiry();
|
|
|
|
|
SendBufferedPackets(now);
|
|
|
|
|
}
|
2021-04-07 08:57:28 +02:00
|
|
|
}
|
|
|
|
|
return absl::nullopt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
absl::optional<DurationMs> TransmissionControlBlock::OnDelayedAckTimerExpiry() {
|
|
|
|
|
data_tracker_.HandleDelayedAckTimerExpiry();
|
|
|
|
|
MaybeSendSack();
|
|
|
|
|
return absl::nullopt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void TransmissionControlBlock::MaybeSendSack() {
|
|
|
|
|
if (data_tracker_.ShouldSendAck(/*also_if_delayed=*/false)) {
|
|
|
|
|
SctpPacket::Builder builder = PacketBuilder();
|
|
|
|
|
builder.Add(
|
|
|
|
|
data_tracker_.CreateSelectiveAck(reassembly_queue_.remaining_bytes()));
|
|
|
|
|
Send(builder);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
dcsctp: Avoid bundling FORWARD-TSN and DATA chunks
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}
2021-08-17 20:50:35 +02:00
|
|
|
void TransmissionControlBlock::MaybeSendForwardTsn(SctpPacket::Builder& builder,
|
|
|
|
|
TimeMs now) {
|
|
|
|
|
if (now >= limit_forward_tsn_until_ &&
|
|
|
|
|
retransmission_queue_.ShouldSendForwardTsn(now)) {
|
|
|
|
|
if (capabilities_.message_interleaving) {
|
|
|
|
|
builder.Add(retransmission_queue_.CreateIForwardTsn());
|
|
|
|
|
} else {
|
|
|
|
|
builder.Add(retransmission_queue_.CreateForwardTsn());
|
|
|
|
|
}
|
|
|
|
|
packet_sender_.Send(builder);
|
|
|
|
|
// https://datatracker.ietf.org/doc/html/rfc3758
|
|
|
|
|
// "IMPLEMENTATION NOTE: An implementation may wish to limit the number of
|
|
|
|
|
// duplicate FORWARD TSN chunks it sends by ... waiting a full RTT before
|
|
|
|
|
// sending a duplicate FORWARD TSN."
|
|
|
|
|
// "Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT exceed
|
|
|
|
|
// 200ms and MUST NOT exceed 500ms".
|
|
|
|
|
limit_forward_tsn_until_ = now + std::min(DurationMs(200), rto_.srtt());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2022-04-22 16:28:33 +02:00
|
|
|
void TransmissionControlBlock::MaybeSendFastRetransmit() {
|
|
|
|
|
if (!retransmission_queue_.has_data_to_be_fast_retransmitted()) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// https://datatracker.ietf.org/doc/html/rfc4960#section-7.2.4
|
|
|
|
|
// "Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked
|
|
|
|
|
// for retransmission will fit into a single packet, subject to constraint of
|
|
|
|
|
// the path MTU of the destination transport address to which the packet is
|
|
|
|
|
// being sent. Call this value K. Retransmit those K DATA chunks in a single
|
|
|
|
|
// packet. When a Fast Retransmit is being performed, the sender SHOULD
|
|
|
|
|
// ignore the value of cwnd and SHOULD NOT delay retransmission for this
|
|
|
|
|
// single packet."
|
|
|
|
|
|
|
|
|
|
SctpPacket::Builder builder(peer_verification_tag_, options_);
|
|
|
|
|
auto chunks = retransmission_queue_.GetChunksForFastRetransmit(
|
|
|
|
|
builder.bytes_remaining());
|
|
|
|
|
for (auto& [tsn, data] : chunks) {
|
|
|
|
|
if (capabilities_.message_interleaving) {
|
|
|
|
|
builder.Add(IDataChunk(tsn, std::move(data), false));
|
|
|
|
|
} else {
|
|
|
|
|
builder.Add(DataChunk(tsn, std::move(data), false));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
packet_sender_.Send(builder);
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-07 08:57:28 +02:00
|
|
|
void TransmissionControlBlock::SendBufferedPackets(SctpPacket::Builder& builder,
|
dcsctp: Don't sent more packets before COOKIE ACK
While in the COOKIE ECHO state, there is a TCB and there might be data
in the send buffer, and RFC4960 allows the COOKIE ECHO chunk to bundle
additional DATA chunks in the same packet, but there mustn't be more
than one such packet sent, and that packet must have a COOKIE ECHO chunk
as the first chunk in it.
When the COOKIE ACK chunk has been received, the socket is allowed to
send multiple packets.
Previously, this was state managed by the socket and not the TCB, as
the socket is responsible for moving between the different states. And
when the COOKIE ECHO chunk was sent, the TCB was instructed to only send
a single packet by the socket.
However, if there were retransmissions or anything else that could
result in calling TransmissionControlBlock::SendBufferedChunks, it would
do as instructed and send those, even if the socket was in a state where
that wasn't allowed.
When the peer was dcSCTP, this didn't cause any issues as dcSCTP tries
to be tolerant in what it receives (but strict in what it sends, except
for when there are bugs). When the peer was usrsctp, it would send an
ABORT for each received packet that didn't have a COOKIE ECHO as the
first chunk, and then restart the handshake (sending an INIT). So this
resulted in a longer handshake, but the connection would eventually be
correctly established and any DATA chunks that resulted in the ABORTs
would've been retransmitted.
By making the TCB aware of that particular state, and to make it
responsible for creating the SCTP packet with the COOKIE ECHO chunk
first, and also to only send a single packet when it is in that state,
there will not be any way to bypass this limitation.
Also, while not explicitly mentioned in the RFC, the retransmission
timer will not affect resending any outstanding DATA chunks that were
bundled together with the COOKIE ECHO chunk, as then there would be two
timers that both would drive resending COOKIE ECHO and DATA chunks.
Bug: webrtc:12880
Change-Id: I76f215a03cceab5bafe9f16eb4775f3dc68a6f05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222645
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34329}
2021-06-16 12:52:42 +02:00
|
|
|
TimeMs now) {
|
2021-08-12 10:48:11 +02:00
|
|
|
for (int packet_idx = 0;
|
|
|
|
|
packet_idx < options_.max_burst && retransmission_queue_.can_send_data();
|
|
|
|
|
++packet_idx) {
|
2021-04-07 08:57:28 +02:00
|
|
|
// Only add control chunks to the first packet that is sent, if sending
|
|
|
|
|
// multiple packets in one go (as allowed by the congestion window).
|
|
|
|
|
if (packet_idx == 0) {
|
dcsctp: Don't sent more packets before COOKIE ACK
While in the COOKIE ECHO state, there is a TCB and there might be data
in the send buffer, and RFC4960 allows the COOKIE ECHO chunk to bundle
additional DATA chunks in the same packet, but there mustn't be more
than one such packet sent, and that packet must have a COOKIE ECHO chunk
as the first chunk in it.
When the COOKIE ACK chunk has been received, the socket is allowed to
send multiple packets.
Previously, this was state managed by the socket and not the TCB, as
the socket is responsible for moving between the different states. And
when the COOKIE ECHO chunk was sent, the TCB was instructed to only send
a single packet by the socket.
However, if there were retransmissions or anything else that could
result in calling TransmissionControlBlock::SendBufferedChunks, it would
do as instructed and send those, even if the socket was in a state where
that wasn't allowed.
When the peer was dcSCTP, this didn't cause any issues as dcSCTP tries
to be tolerant in what it receives (but strict in what it sends, except
for when there are bugs). When the peer was usrsctp, it would send an
ABORT for each received packet that didn't have a COOKIE ECHO as the
first chunk, and then restart the handshake (sending an INIT). So this
resulted in a longer handshake, but the connection would eventually be
correctly established and any DATA chunks that resulted in the ABORTs
would've been retransmitted.
By making the TCB aware of that particular state, and to make it
responsible for creating the SCTP packet with the COOKIE ECHO chunk
first, and also to only send a single packet when it is in that state,
there will not be any way to bypass this limitation.
Also, while not explicitly mentioned in the RFC, the retransmission
timer will not affect resending any outstanding DATA chunks that were
bundled together with the COOKIE ECHO chunk, as then there would be two
timers that both would drive resending COOKIE ECHO and DATA chunks.
Bug: webrtc:12880
Change-Id: I76f215a03cceab5bafe9f16eb4775f3dc68a6f05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222645
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34329}
2021-06-16 12:52:42 +02:00
|
|
|
if (cookie_echo_chunk_.has_value()) {
|
|
|
|
|
// https://tools.ietf.org/html/rfc4960#section-5.1
|
|
|
|
|
// "The COOKIE ECHO chunk can be bundled with any pending outbound DATA
|
|
|
|
|
// chunks, but it MUST be the first chunk in the packet..."
|
|
|
|
|
RTC_DCHECK(builder.empty());
|
|
|
|
|
builder.Add(*cookie_echo_chunk_);
|
|
|
|
|
}
|
|
|
|
|
|
2021-04-07 08:57:28 +02:00
|
|
|
// https://tools.ietf.org/html/rfc4960#section-6
|
|
|
|
|
// "Before an endpoint transmits a DATA chunk, if any received DATA
|
|
|
|
|
// chunks have not been acknowledged (e.g., due to delayed ack), the
|
|
|
|
|
// sender should create a SACK and bundle it with the outbound DATA chunk,
|
|
|
|
|
// as long as the size of the final SCTP packet does not exceed the
|
|
|
|
|
// current MTU."
|
|
|
|
|
if (data_tracker_.ShouldSendAck(/*also_if_delayed=*/true)) {
|
|
|
|
|
builder.Add(data_tracker_.CreateSelectiveAck(
|
|
|
|
|
reassembly_queue_.remaining_bytes()));
|
|
|
|
|
}
|
2022-04-20 10:10:38 +02:00
|
|
|
MaybeSendForwardTsn(builder, now);
|
2021-04-07 08:57:28 +02:00
|
|
|
absl::optional<ReConfigChunk> reconfig =
|
|
|
|
|
stream_reset_handler_.MakeStreamResetRequest();
|
|
|
|
|
if (reconfig.has_value()) {
|
|
|
|
|
builder.Add(*reconfig);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
auto chunks =
|
|
|
|
|
retransmission_queue_.GetChunksToSend(now, builder.bytes_remaining());
|
2022-01-10 12:52:13 +01:00
|
|
|
for (auto& [tsn, data] : chunks) {
|
2021-04-07 08:57:28 +02:00
|
|
|
if (capabilities_.message_interleaving) {
|
|
|
|
|
builder.Add(IDataChunk(tsn, std::move(data), false));
|
|
|
|
|
} else {
|
|
|
|
|
builder.Add(DataChunk(tsn, std::move(data), false));
|
|
|
|
|
}
|
|
|
|
|
}
|
2021-08-12 15:57:49 +02:00
|
|
|
|
|
|
|
|
if (!packet_sender_.Send(builder)) {
|
2021-04-07 08:57:28 +02:00
|
|
|
break;
|
|
|
|
|
}
|
dcsctp: Don't sent more packets before COOKIE ACK
While in the COOKIE ECHO state, there is a TCB and there might be data
in the send buffer, and RFC4960 allows the COOKIE ECHO chunk to bundle
additional DATA chunks in the same packet, but there mustn't be more
than one such packet sent, and that packet must have a COOKIE ECHO chunk
as the first chunk in it.
When the COOKIE ACK chunk has been received, the socket is allowed to
send multiple packets.
Previously, this was state managed by the socket and not the TCB, as
the socket is responsible for moving between the different states. And
when the COOKIE ECHO chunk was sent, the TCB was instructed to only send
a single packet by the socket.
However, if there were retransmissions or anything else that could
result in calling TransmissionControlBlock::SendBufferedChunks, it would
do as instructed and send those, even if the socket was in a state where
that wasn't allowed.
When the peer was dcSCTP, this didn't cause any issues as dcSCTP tries
to be tolerant in what it receives (but strict in what it sends, except
for when there are bugs). When the peer was usrsctp, it would send an
ABORT for each received packet that didn't have a COOKIE ECHO as the
first chunk, and then restart the handshake (sending an INIT). So this
resulted in a longer handshake, but the connection would eventually be
correctly established and any DATA chunks that resulted in the ABORTs
would've been retransmitted.
By making the TCB aware of that particular state, and to make it
responsible for creating the SCTP packet with the COOKIE ECHO chunk
first, and also to only send a single packet when it is in that state,
there will not be any way to bypass this limitation.
Also, while not explicitly mentioned in the RFC, the retransmission
timer will not affect resending any outstanding DATA chunks that were
bundled together with the COOKIE ECHO chunk, as then there would be two
timers that both would drive resending COOKIE ECHO and DATA chunks.
Bug: webrtc:12880
Change-Id: I76f215a03cceab5bafe9f16eb4775f3dc68a6f05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222645
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34329}
2021-06-16 12:52:42 +02:00
|
|
|
|
|
|
|
|
if (cookie_echo_chunk_.has_value()) {
|
|
|
|
|
// https://tools.ietf.org/html/rfc4960#section-5.1
|
|
|
|
|
// "... until the COOKIE ACK is returned the sender MUST NOT send any
|
|
|
|
|
// other packets to the peer."
|
2021-04-07 08:57:28 +02:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::string TransmissionControlBlock::ToString() const {
|
|
|
|
|
rtc::StringBuilder sb;
|
|
|
|
|
|
|
|
|
|
sb.AppendFormat(
|
|
|
|
|
"verification_tag=%08x, last_cumulative_ack=%u, capabilities=",
|
|
|
|
|
*peer_verification_tag_, *data_tracker_.last_cumulative_acked_tsn());
|
|
|
|
|
|
|
|
|
|
if (capabilities_.partial_reliability) {
|
|
|
|
|
sb << "PR,";
|
|
|
|
|
}
|
|
|
|
|
if (capabilities_.message_interleaving) {
|
|
|
|
|
sb << "IL,";
|
|
|
|
|
}
|
|
|
|
|
if (capabilities_.reconfig) {
|
|
|
|
|
sb << "Reconfig,";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return sb.Release();
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-17 15:32:48 +02:00
|
|
|
HandoverReadinessStatus TransmissionControlBlock::GetHandoverReadiness() const {
|
|
|
|
|
HandoverReadinessStatus status;
|
|
|
|
|
status.Add(data_tracker_.GetHandoverReadiness());
|
|
|
|
|
status.Add(stream_reset_handler_.GetHandoverReadiness());
|
|
|
|
|
status.Add(reassembly_queue_.GetHandoverReadiness());
|
|
|
|
|
status.Add(retransmission_queue_.GetHandoverReadiness());
|
|
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void TransmissionControlBlock::AddHandoverState(
|
|
|
|
|
DcSctpSocketHandoverState& state) {
|
|
|
|
|
state.capabilities.partial_reliability = capabilities_.partial_reliability;
|
|
|
|
|
state.capabilities.message_interleaving = capabilities_.message_interleaving;
|
|
|
|
|
state.capabilities.reconfig = capabilities_.reconfig;
|
|
|
|
|
|
|
|
|
|
state.my_verification_tag = my_verification_tag().value();
|
|
|
|
|
state.peer_verification_tag = peer_verification_tag().value();
|
|
|
|
|
state.my_initial_tsn = my_initial_tsn().value();
|
|
|
|
|
state.peer_initial_tsn = peer_initial_tsn().value();
|
|
|
|
|
state.tie_tag = tie_tag().value();
|
|
|
|
|
|
|
|
|
|
data_tracker_.AddHandoverState(state);
|
|
|
|
|
stream_reset_handler_.AddHandoverState(state);
|
|
|
|
|
reassembly_queue_.AddHandoverState(state);
|
|
|
|
|
retransmission_queue_.AddHandoverState(state);
|
|
|
|
|
}
|
2022-06-27 20:35:37 +00:00
|
|
|
|
|
|
|
|
void TransmissionControlBlock::RestoreFromState(
|
|
|
|
|
const DcSctpSocketHandoverState& state) {
|
|
|
|
|
data_tracker_.RestoreFromState(state);
|
|
|
|
|
retransmission_queue_.RestoreFromState(state);
|
|
|
|
|
reassembly_queue_.RestoreFromState(state);
|
|
|
|
|
}
|
2021-04-07 08:57:28 +02:00
|
|
|
} // namespace dcsctp
|