commit 3f981ee9797a3db969ece21263c07388a05eaa43
author Victor Boivie <boivie@webrtc.org> Thu Oct 14 20:28:43 2021
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Oct 15 09:08:24 2021
tree 5d9e531bde1d94deef2d97f41d1e74ea1b194d49
parent ff70925ca85805fa93237909da2286916729fac6

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}