tree 5d9e531bde1d94deef2d97f41d1e74ea1b194d49
parent ff70925ca85805fa93237909da2286916729fac6
author Victor Boivie <boivie@webrtc.org> 1634243323 +0200
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> 1634288904 +0000

dcsctp: Support zero window probing

This is explained in RFC 4960, section 6.1, A.

  ... However, regardless of the value of rwnd (including if it
  is 0), the data sender can always have one DATA chunk in flight to
  the receiver if allowed by cwnd ...  This rule
  allows the sender to probe for a change in rwnd that the sender
  missed due to the SACK's having been lost in transit from the data
  receiver to the data sender.

Before this change, when a receiver has advertised a zero receiver
window size (a_rwnd=0) and a subsequent SACK advertising a non-zero
receiver window was lost, the sender was blocked from sending and since
SACKs are only sent when a DATA chunk is received, it would be
deadlocked. The retransmission timer would fire, but nothing would be
retransmitted (as it respected the zero receiver window).

With this change, when the retransmission timer fires (after RTO), it
would send a single packet with DATA chunk(s) and then SACKs would
eventually be received, with the non-zero receiver window and the socket
would recover.

Bug: chromium:1258225
Change-Id: I1ea62fb3c002150eeada28d3e703dbc09cfd038e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235280
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35215}