Solved: TCP MSS and its windows size

dannan lin · ‎11-18-2022

hi guys:

I am trying to clarify my understanding about TCP MSS and sliding window. let's put it simple

As far as i know ,MSS means the maximum payload for the frame.

The "sliding window " enables TCP to send consecutive segments before it gets an ACK.

based on the packets i had captured , Frame 1276 states that the receiver has the window size if 8195, the length of the payload is 1460 each. Frame 1286 gives the acknowledgement of frame 1285.

I know ACK 585948 (frame 1285) is caculated by SEQ 572808(frame 1277) plus 9 segments of data length(1460 X 9) , it all make sense to me .

but, here comes the question, if the windows size of receiver is only 8195 byte(frame 1276,1286), how can a sender send 13140 byte before it get an acknowledgement? did i miss anything? i am quite confused here, any help will be appreciated.

Joseph W. Doherty · ‎11-18-2022

"As far as i know ,MSS means the maximum payload for the frame."

Incorrect, although commonly the case.

"The "sliding window " enables TCP to send consecutive segments before it gets an ACK."

Correct, but the sliding window is on the sender's side. I.e. sender can send as many outstanding (not yet ACKed) segments as long as the sending window size (which grows and shrinks, dynamically) AND which do not overflow the receiver's buffer. (BTW, "spoofing" the latter is one technique that in-path traffic shapers use to throttle a sender's transmission rate.)

In regard to youR question, how could the sender violate the rule just described (by both of us), I wonder if this TCP exchange is using big buffers (i.e. greater than 64KB), if so, when it's setup, possibly it's being done with a binary scaling factor (TCP window scaling). I'm unsure what available free buffer space represents when that's being used.

View solution in original post

Joseph W. Doherty · ‎11-18-2022

"As far as i know ,MSS means the maximum payload for the frame."

Incorrect, although commonly the case.

"The "sliding window " enables TCP to send consecutive segments before it gets an ACK."

Correct, but the sliding window is on the sender's side. I.e. sender can send as many outstanding (not yet ACKed) segments as long as the sending window size (which grows and shrinks, dynamically) AND which do not overflow the receiver's buffer. (BTW, "spoofing" the latter is one technique that in-path traffic shapers use to throttle a sender's transmission rate.)

In regard to youR question, how could the sender violate the rule just described (by both of us), I wonder if this TCP exchange is using big buffers (i.e. greater than 64KB), if so, when it's setup, possibly it's being done with a binary scaling factor (TCP window scaling). I'm unsure what available free buffer space represents when that's being used.

dannan lin · ‎11-18-2022

thanks a lot, my set up was fairly simple, i was downloading files from my local NAS server and i found this "abnormality". I looked up the scaling factor, it was "-1", Could that be the reason?