09-02-2015 02:23 AM - edited 03-05-2019 02:12 AM
hi guys,
my question is related to the MSS value. I'm referring to (hope it's not outdated):
"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
09-02-2015 05:14 AM
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.)
09-02-2015 05:42 AM
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 ?
09-02-2015 07:31 AM
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.
09-03-2015 12:28 AM
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
09-03-2015 01:47 AM
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.
09-06-2015 01:03 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide