MSS calculation

[AdamBudzinski]

hi guys,

my question is related to the MSS value. I'm  referring to (hope it's not outdated):

http://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html

"The way MSS now works is that each host will first compare its outgoing interface MTU with its own buffer and choose the lowest value as the MSS to send. The hosts will then compare the MSS size received against their own interface MTU and again choose the lower of the two values."

If we consider two hosts communicating in LAN, the Ethernet Frame defines that the size of a single packet encapsulated in the Eth Frame cannot be larger as 1500 bytes (MTU value). From what I understood the Data Link Layer is "communicating" this to the Network Layer. If we subtract the  min. 20 bytes of the IP Header we are left with 1480 bytes. If we subtract the min. TCP Header of 20 bytes we are left with 1460 bytes = MSS. 

I don't get the part with "each host will first compare its outgoing interface MTU with its own buffer and choose the lowest value as the MSS to send."

According to the command below  the MTU value for my interfaces is 1500 bytes. 

I

Now, what is the buffer ? I was sure that it is the Window Size, or are they referring to following settings: 

According to :

http://www.ietf.org/rfc/rfc879.txt?referring_site=bodynav

"

To notify the data sender of the largest TCP segment it is possible

   to receive the calculation of the MSS value to send is:

      MSS = MTU - sizeof(TCPHDR) - sizeof(IPHDR)" 

They do not mention any buffers. 

Me personally, i cannot imagine how the buffer comes here in to play. From what I understand the MSS values are exchanged during the 3 way handshake in the SYN packets and remain the same for the whole conversation. 

can you please help me with this ?

Best Regards 

Adam 

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I don't get the part with "each host will first compare its outgoing interface MTU with its own buffer and choose the lowest value as the MSS to send."

I suspect you're being confused by "buffer".  Within a system or network, there are many different buffers.  The one being referred to here, I believe, is TCP segment buffers.  I also believe, by default, TCP wants to use its maximum possible logical segment size, 64K, but when it determines the MTU is smaller, it adjust its maximum segment size (MSS) to fit within a single packet.

The reason the TCP segments are buffered, for transmission, they might be waiting for the network driver to accept them, and for reception, insuring they are provided to the TCP application in sequence.  (The latter is TCP's receive window [RWIN].)

During TCP handshake, the two hosts examine each other's MSS and use the lessor value.

The other buffers you're looking at are NIC buffers.  These buffers are used to store frames for reception or transmission.  There are fixed sized, so individual frames may require more than one.  Also, as frame sizes are variable, fixed buffers will have "wasted" space, but that a trade-off to simplify buffer management.  (Similar concept to how most disk drives have fixed size sectors and/or allocation clusters for space management.)

[AdamBudzinski]

The reason the TCP segments are buffered, for transmission, they might be waiting for the network driver to accept them, and for reception, insuring they are provided to the TCP application in sequence.  (The latter is TCP's receive window [RWIN].)

Ok, so basically the size of  send and receive buffers is the windows size, correct ? That is, window size represents how much data a device can handle from its peer at one time before it is passed to the application process. So in case, like you wrote "they might be waiting for the network driver to accept them, and for reception, insuring they are provided to the TCP application in sequence" the receiving host will advertiste a lower window size to the sending host, which in turns will shrink the receive buffer on the receiving host, correct ? 

The other buffers you're looking at are NIC buffers.  These buffers are used to store frames for reception or transmission.  There are fixed sized, so individual frames may require more than one.  Also, as frame sizes are variable, fixed buffers will have "wasted" space, but that a trade-off to simplify buffer management.  (Similar concept to how most disk drives have fixed size sectors and/or allocation clusters for space management.)

ok, so if mine transmit buffer is 512 bytes (as you can see on the above screen shot) and (just theoretically saying) i would have few 64 bytes Ethernet II Frames waiting for transmission m 8 of them would be store in this buffer, correct  ? 

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Ok, so basically the size of  send and receive buffers is the windows size, correct ? That is, window size represents how much data a device can handle from its peer at one time before it is passed to the application process.

For the TCP receiver, yes.  For the transmitter, the send window is adjusted based on how well data is getting from the sender to the receiver.

. . . the receiving host will advertiste a lower window size to the sending host, which in turns will shrink the receive buffer on the receiving host, correct ? 

The receiving host advertises how much buffer space there is with every ACK.  The sender won't overflow what the receiver has available, but the sender's send window might be smaller due to its flow control.

ok, so if mine transmit buffer is 512 bytes (as you can see on the above screen shot) and (just theoretically saying) i would have few 64 bytes Ethernet II Frames waiting for transmission m 8 of them would be store in this buffer, correct  ? 

It depends on the implementation of the driver, but often there will be not be more than one frame per buffer, although a large frame might consume multiple buffers.

[AdamBudzinski]

Thank you, just  one more question.

During TCP handshake, the two hosts examine each other's MSS and use the lessor value.

In LAN, should the MSS value be same on both ends  ( I mean as soon the MTU is matching on each host NIC's ?). Or can they vary ? If yes, what could be the reason ? 

What about when we communicate with a host outside our LAN? 

Best Regards

Adam 

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

If hosts are on the same kind of media, e.g. Ethernet, normally their MTUs will match regardless whether they're on the same LAN or not.  If they are on different media, e.g. Ethernet and Token Ring, generally their MTUs will differ.  Of course, today, you don't see hosts too often on different media, but also today, even on Ethernet, one host might be on standard Ethernet and the other on Jumbo Ethernet.

[Peter Koltl]

This is my favorite Cisco document. (-: I always refer to it when someone wants to add an mtu command when working with IPsec or GRE.