large length tcp field during SMB2 copy

Question

Hi,

I have a trace for SMB2 file copying. When I check this trace, I saw traffic pattern like this during the transfer.

(the trace is captured from the server, clients are copying data from the server)

----------
[server -> client, length = 62823bytes]
[server -> client, length = 2788bytes]
[client -> server, length = 0, tcp ACK]
[client -> server, length = 0, tcp ACK]
[…..]
[tens of same packets omitted]
[…..]
[client -> server, length = 0, tcp ACK]
[server -> client, length = 32844bytes]
[client -> server, length = 0, tcp ACK]
[…..]
[tens of same packets omitted]
[…..]
[client -> server, length = 0, tcp ACK]
[….]
———-

I understand that those tens of Acks are for different tcp data transfer segments. But shouldn’t I expect to see tens of data transfer tcp segments followed by Acks? Why wireshark only shows one SMB2 packet with a very large, bigger than common 1460 TCP segment, packet followed by all of the Ackes? Like the following:

———-
[server -> client, length = 1460bytes]
[server -> client, length = 1460bytes]
[server -> client, length = 1460bytes]
[…..]
[server -> client, length = 1460bytes]
[server -> client, length = 1460bytes]
[client -> server, length = 0, Ack1]
[client -> server, length = 0, Ack2]
[……]
———-

Could anyone let me know the insides?

thanks a lot!

Accepted Answer

4

As you can see the frames seen by wireshark are very large. That's due to TCP offloading into the NIC driver. The driver will split those 'large frames' into a lot of smaller frames (according to the MTU). The client then answers to 'some' (or all) of those frames with an ACK.

Regards
Kurt

answered 25 Dec '13, 00:29

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 25 Dec '13, 07:43

More likely it is answering to each other frame with an ack, at least Windows does. So there should roughly be one ack packet per two packets carrying data segments.

(25 Dec '13, 02:48) Jasper ♦♦

You're of course right. So, my wording (ACK for each frame) was not correct ;-) See my correction in the answer.

(25 Dec '13, 05:12) Kurt Knochner ♦

so if disable TCP offloading on the server, should I expect to see patters like below?

[server -> client, length = 1460bytes]
[server -> client, length = 1460bytes]
[server -> client, length = 1460bytes]
[.....]
[server -> client, length = 1460bytes]
[server -> client, length = 1460bytes]
[client -> server, length = 0, Ack1]
[client -> server, length = 0, Ack2]
[......]

(26 Dec '13, 06:35) SteveZhou

More or less. You will see the same if you capture at the client.

(26 Dec '13, 07:56) Kurt Knochner ♦

I checked the NIC properties on the server, we have Large send offload enabled, is it the TCP offloading you referred to?

(26 Dec '13, 18:32) SteveZhou

I have confirmed that after disabling LSO, we are now seeing bunch of 1460bytes of TCP segment followed by acks. But the wireshark response became really slow during the capturing. After re-enabling the LSO, no sluggish on the wireshark GUI anymore.

(26 Dec '13, 22:56) SteveZhou

what do you mean by "wireshark response became really slow during the capturing"? Did the 'reaction time' of the GUI change in any way?

(27 Dec '13, 03:53) Kurt Knochner ♦

showing 5 of 7 show 2 more comments