I use tcpdump to troubleshot network problem, and found one record that ack number is greater than sack number:

Why ack number greater than sack number?
This is compatible with a Duplicate Selective Acknowledgement as described in RFC 2883 which adds DSACK to the SACK mechanism described in RFC 2018.
Here's an example from the RFC:
Because several ACK packets are lost, the data sender retransmits packet 3000-3499, and the data receiver subsequently receives a duplicate segment with sequence numbers 3000-3499. The receiver sends an acknowledgement with the cumulative acknowledgement field set to 4000, and the first, D-SACK block specifying sequence numbers 3000-3500.
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks) 3000-3499 3000-3499 3500 (ACK dropped) 3500-3999 3500-3999 4000 (ACK dropped) 3000-3499 3000-3499 4000, SACK=3000-3500 ---------
Section 5 describes how to identify a DSACK:
In order for the sender to check that the first (D)SACK block of an acknowledgement in fact acknowledges duplicate data, the sender should compare the sequence space in the first SACK block to the cumulative ACK which is carried IN THE SAME PACKET. If the SACK sequence space is less than this cumulative ACK, it is an indication that the segment identified by the SACK block has been received more than once by the receiver.
So in this case ACK > SACK. This should happen only if packets from receiver to sender (meaning ACKs) got lost which then later triggered a (useless) resend of data from the sender which is even later reported back from the receiver to the sender with a DSACK. This information might be used in some congestion algorithms. I can't know if this is compatible with your capture, but that's something to check.
For example, on Linux DSACK is probably active by default:
# sysctl -ar 'net\.ipv4\.tcp_d?sack'
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1