TCP packet TSval, TSecr

Question

My application is creating a connection to Redis and using redis to store key/value. I am using lettuce library.

I took packet capture / wireshark on my application.

I saw one packet (from application to redis ) and could not understand who is sending it either lettuce or OS ?

I am seeing some slowness ( 30-70 millisecond ) to send command to redis when this ACK is happening. Is there any way to stop it ?

Below is the packet details . I copied it from wireshark.

75973 2025年03月21日 18:51:07.914 10.32.13.202 10.32.13.211 TCP 68 3714 → 6379 [ACK] Seq=78850 Ack=7724 Win=58 Len=0 TSval=2556602378 TSecr=779563942
Frame 75973: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
 Encapsulation type: Linux cooked-mode capture v1 (25)
 Arrival Time: Mar 22, 2025 00:21:07.914380000 India Standard Time
 UTC Arrival Time: Mar 21, 2025 18:51:07.914380000 UTC
 Epoch Arrival Time: 1742583067.914380000
 [Time shift for this packet: 0.000000000 seconds]
 [Time delta from previous captured frame: 0.000122000 seconds]
 [Time delta from previous displayed frame: 0.040982000 seconds]
 [Time since reference or first frame: 9.318908000 seconds]
 Frame Number: 75973
 Frame Length: 68 bytes (544 bits)
 Capture Length: 68 bytes (544 bits)
 [Frame is marked: False]
 [Frame is ignored: False]
 [Protocols in frame: sll:ethertype:ip:tcp]
 [Coloring Rule Name: TCP]
 [Coloring Rule String: tcp]
Linux cooked capture v1
 Packet type: Sent by us (4)
 Link-layer address type: Ethernet (1)
 Link-layer address length: 6
 Source: VMware_8f:c1:bc (00:50:56:8f:c1:bc)
 Unused: 003a
 Protocol: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.32.13.202, Dst: 10.32.13.211
 0100 .... = Version: 4
 .... 0101 = Header Length: 20 bytes (5)
 Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
 Total Length: 52
 Identification: 0x0544 (1348)
 010. .... = Flags: 0x2, Don't fragment
 ...0 0000 0000 0000 = Fragment Offset: 0
 Time to Live: 64
 Protocol: TCP (6)
 Header Checksum: 0x0520 [validation disabled]
 [Header checksum status: Unverified]
 Source Address: 10.32.13.202
 Destination Address: 10.32.13.211
 [Stream index: 1]
Transmission Control Protocol, Src Port: 3714, Dst Port: 6379, Seq: 78850, Ack: 7724, Len: 0
 Source Port: 3714
 Destination Port: 6379
 [Stream index: 25]
 [Stream Packet Number: 3156]
 [Conversation completeness: Incomplete (12)]
 [TCP Segment Len: 0]
 Sequence Number: 78850 (relative sequence number)
 Sequence Number (raw): 2739616864
 [Next Sequence Number: 78850 (relative sequence number)]
 Acknowledgment Number: 7724 (relative ack number)
 Acknowledgment number (raw): 2040541672
 1000 .... = Header Length: 32 bytes (8)
 Flags: 0x010 (ACK)
 Window: 58
 [Calculated window size: 58]
 [Window size scaling factor: -1 (unknown)]
 Checksum: 0x3087 [unverified]
 [Checksum Status: Unverified]
 Urgent Pointer: 0
 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
 TCP Option - No-Operation (NOP)
 TCP Option - No-Operation (NOP)
 TCP Option - Timestamps: TSval 2556602378, TSecr 779563942
 Kind: Time Stamp Option (8)
 Length: 10
 Timestamp value: 2556602378
 Timestamp echo reply: 779563942
 [Timestamps]
 [SEQ/ACK analysis]
 [This is an ACK to the segment in frame: 75731]
 [The RTT to ACK the segment was: 0.040982000 seconds]

• erickson: You know your own IP address and ports, so you should easily be able to identify the traffic direction; assuming you didn't change the default Redis port, this is a packet from your client to Redis service. It is empty, acknowledging a previous packet from the server 41 ms prior. What is your question?