sriram.yagnaraman@xxxxxxxx <sriram.yagnaraman@xxxxxxxx> wrote: > From: Sriram Yagnaraman <sriram.yagnaraman@xxxxxxxx> > > SCTP conntrack currently assumes that the SCTP endpoints will > probe secondary paths using HEARTBEAT before sending traffic. > > But, according to RFC 9260, SCTP endpoints can send any traffic > on any of the confirmed paths after SCTP association is up. > SCTP endpoints that sends INIT will confirm all peer addresses > that upper layer configures, and the SCTP endpoint that receives > COOKIE_ECHO will only confirm the address it sent the INIT_ACK to. > > So, we can have a situation where the INIT sender can start to > use secondary paths without the need to send HEARTBEAT. This patch > allows DATA/SACK packets to create new connection tracking entry. > > A new state has been added to indicate that a DATA/SACK chunk has > been seen in the original direction - SCTP_CONNTRACK_DATA_SENT. > State transitions mostly follows the HEARTBEAT_SENT, except on > receiving HEARTBEAT/HEARTBEAT_ACK/DATA/SACK in the reply direction. > > State transitions in original direction: > - DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks, > except that it remains in DATA_SENT on receving HEARTBEAT, > HEARTBEAT_ACK/DATA/SACK chunks > State transitions in reply direction: > - DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks, > except that it moves to HEARTBEAT_ACKED on receiving > HEARTBEAT/HEARTBEAT_ACK/DATA/SACK chunks Looks OK to me.
