From rfc 9293:
A TCP implementation MAY send an ACK segment acknowledging RCV.NXT when a valid segment arrives that is in the window but not at the left window edge (MAY-13).
But isn't RCV.NXT the left window edge?
From the same rfc:
RCV.NXT = next sequence number expected on an incoming segment, and is the left or lower edge of the receive window
So if I receive a segment with sequence number 10, and RCV.NXT is 10, it shouldnt send an ACK?
A receive window is the size of the receive buffer, and the receiver communicates that in an acknowledgement, and that defines the window size to the sender. The acknowledgement sets the windows size, so that is the left edge of the window.
A sender can send up to the window size before it must pause to wait for and acknowledgement. The receiver does not need to send an acknowledgement for any segments received within the receive window, but it may. Once the receiver sends an acknowledgment, and that will contain a new receive window size, then that defines a new receive window, so it is the left edge of the new window, and the sender can continue to send until the new window is exhausted, or it receives a new acknowledgment that will have a new receive window.
In practice, it is fairly rare that a sender exhausts the receive window, needing to pause until it receives an acknowledgment. That means that the receive window is redefined by an acknowledgement prior to the exhaustion of the window, creating a new receive window.
(1) MAY-13 is according to Appendix B "Send ACK for out-of-order segment". Out-of-order segment is the segment that is NOT the next expected segment, i.e., the one that is not RCV.NXT. This happens when the next expected segment is lost, or the segments are reordered for some reason.
The ACK mechanism in TCP is as follows: TCP always sends the next expected sequence number in ACK. When new in-order segment arrives, the receiver updates RCV.NXT and sends ACK. When out of order segment arrives, the receiver sends an ACK for RCV.NXT, which is a duplicate ACK (another ACK with this value is already sent). The sender notes how many duplicate ACKs have arrived. After receiving 3 (or dupack threshold) duplicate ACKs, sender assumes that the segment is lost and acts accordingly.
The word MAY refers to - it is up to the implementation on whether to actually implement it or not. Technically, TCP should work correctly if duplicate ACKs are not sent: retransmissions will be eventually triggered by retransmission timer. The performance however will be reduced significantly, so I would assume that most implementations do send these ACKs.
Also, loss recovery is a pretty complex topic in TCP. There are quite a number of other RFCs that specify how loss recovery is done. This includes for example selective acknowledgements (SACKs), which, in addition to sending ACK for RCV.NXT also send a TCP option listing what segments are missing. See Sec 3.3 of RFC7414 for a list.
(2) TCP has a mechanism, called delayed acknowledgements. In order to reduce the number of ACKs sent, when TCP receives in-order segments, it does not acknowledge every one of them. The standard recommendation is to acknowledge every other in-order received segment, and ensure that the ACK is not delayer by more than half a second. Since TCP is window-based and uses cumulative ACKs, this is not a problem. The mechanism is explained in Sec 3.8.6.3.
