ACK and WindowSize and MTU and MSS

[Calin Iaru]

Hi all,

I am working on a sockets program. therefore I need more
info on Maximum Segment Size like how do I obtain it, why
would a WindowSize exist since the ACK packet is sent for
every other packet received and so on. I\ll take it one at
a time:

1)"the receive window specifies the number of bytes a
sender can transmit without receiving an ACK. For highest
efficiency, the receive window must be a multiple of the
TCP Maximum segment Size" MSDN

what confuses me is an article from KB 328890 that
states this:

" Instead of sending an acknowledgment for each TCP
segment received, TCP in Windows 2000 and later takes a
common approach to implementing delayed acknowledgments.
As data is received by TCP on a particular connection, it
sends an acknowledgment back only if one of the following
conditions is true:
No acknowledgment was sent for the previous segment
received.
A segment is received, but no other segment arrives within
200 milliseconds for that connection."

It seems that no matter what the size of the window is,
ACK occurs at every two kernel receives, or it can be
configurable. Then, what's the purpose of the window?

2)What is the difference between MTU defined as maximum
packet size in bytes that the transport transmits over the
network (in msdn words) and maximum segment size.
And how are these who calculated or deduced, how can I see
them from user space, and finally, how do they influence
the ACK?
I know that standard Ethernet MTU is 1460 bytes, but I am
working with a non standard adapter and technology. I also
know that "segment" means TCP layer, packet means Ethernet
layer. But I don't see the data flow.
The key word of this e-mail is "tcp window size" (actualy
three ), and I need to know more about this and ACK and
delayed ACK.

Best regards,
Calin

 

[Kent W. England [MVP]]

Calin Iaru wrote on 16-Sep-2004 2:43 PM:

It seems that no matter what the size of the window is,
ACK occurs at every two kernel receives, or it can be
configurable. Then, what's the purpose of the window?

The window allows the sender to "fill the pipe". Here is a little
thought experiment to demonstrate.

Assume we have no window. A packet travels from the source to the sink
and then an acknowledgement travels back. Another packet is sent and
another ack goes back. There is a lot of time spent waiting for packets
to travel the length of the pipe. This is a waste of bandwidth.

Assume we have a large window. The sender sends out a lot of packets
rapidly filling the transmission channels and router buffers on the path
to the sink. The sender sends all the packets allowed and then stops and
waits for an ack. The ack for the first packet returns and the Nth
packet is sent. The ack for the second packet returns right after the
first, because the second packet arrived right after the first. There is
no round-trip-time wait. The pipe is full of data all the time, but the
sender is regulated by the acks, so that the rate matches the channel.

The acks clock packets into the pipe, adding another as each is taken
out. This results in eliminating the RTT wait entirely, so long as the
window is large enough to fill the pipe.

Delayed acks are a finesse on the basic design I just described. There
is still disagreement over whether delayed acks are a good idea. As with
all protocol decisions, there are trade-offs of efficiency versus
response time.

 

[Hans-Georg Michna]

It seems that no matter what the size of the window is,
ACK occurs at every two kernel receives, or it can be
configurable. Then, what's the purpose of the window?

Calin,

the purpose of the receive window (RWIN) is that the sender can
keep sending up to the RWIN size before having to wait for ACK.

I know that standard Ethernet MTU is 1460 bytes ...

Should be 1500 or 1492 if PPPoE is used, because of 8 bytes
protocol overhead.

Sorry, no answer to your second question.

Hans-Georg

p.s. Oops, didn't see Kent's reply in time. Will send this one
anyway.