Talk:Maximum segment size

Why MSS is needed at all?

It would be nice if the article could point out why an MSS value is necessary, since we already have an MTU and a PMTU; isn't the MSS redundant? 195.56.53.118 22:32, 2 November 2006 (UTC)

I'd like to know this too. I came here specifically to find out an answer to this because I cannot see the point of it when there's an MTU 112.204.173.97 (talk) 02:07, 8 May 2022 (UTC)

Error in article: header size is 40 bytes for IPv4

Per section 18.4 of TCP/IP Illustrated Volume 1, headers total 40 bytes with IPv4. 20 bytes for IP, 20 bytes for TCP, so MSS should be MTU-40.

I've never contributed to Wikipedia, and I don't know anything about IPv6, so I can't say whether that part of the article is accurate or not, so I haven't made an edit. —Preceding unsigned comment added by Tomlogic (talk • contribs) 22:38, 7 November 2006

Comments on the above

I'm pretty sure that MTU is a parameter used by the IP stack software or something else at about that level. It says, in effect "If you encounter an outbound packet larger than this, fragment it." MSS is a parameter used by the program actually generating messages that says "block your message into chunks no larger than this so we don't have to fragment it later". I think MSS might apply only to TCP whereas MTU applies to UDP and any other data scheme that uses IP. PMTU is an algorithm/technique that is used to dynamically determine the maxmum usable MTU for a link.

It does seem to me also that one article with a couple of links could probably handle all three concepts.

Yes, I believe that the TCP header is almost always 40 bytes. It's the 'almost' that troubles me. See [1] and search for the phrase "TCP options expanding the header". TCP options?

I considering getting back into working on Wikipedia after a lapse of several years. But it's a vastly different (and better) resource than it was back when there were only a few thousand articles and the objective was to get credible content. I don't plan to start up by tinkering with articles on subjects that I possibly don't understand all that well. I'll check back in a month or so and see where this stands 72.92.156.173 14:00, 23 November 2006 (UTC)

MSS is TCP-specific

The article should point out that MSS is a TCP term; it starts by defining it as some general thing between "communication devices", then slips over to talk about TCP as if it was a special case. (Or has the term been generalized, and I've missed it?) JöG (talk) 11:52, 24 March 2009 (UTC)

MSS vs MTU

If you put MSS and MTU into the correct layers it becomes much clearer. MTU is the maximum physical amount of data that can be moved in one piece on layer 2, usually limited by hardware.
Since layer 3 (IP) employs layer 2 and is in turn used by layer 4 (TCP), both of these must not transmit more data than can be physically transported. For TCP's layer 4 this amount is MSS = MTU - overhead (2x20 bytes for IPv4 over Ethernet).
Sometimes however hardware restrictions do not directly apply, so MSS is a matter of arbitration (e.g. PPP). -- Zac67 (talk) 20:08, 18 August 2009 (UTC)

Too much detail

I think this is excessive detail, so I moved it to talk:

TCP and IPv4 headers are 20 bytes long each, whereas an IPv6 header is 40 bytes long, so the MSS is equal to MTU minus 40 when using IPv4, and MTU minus 60 when using IPv6 (typical MTU for Ethernet is 1500 bytes).

How-to-ish

This has too much of a 'how to' sound to it, so I moved it to the talk page for discussion:

Thus if the IP datagrams carrying the segments are as large as possible, we use the optimum segment size to avoid fragmentation. Although this may be difficult to achieve, it can be beneficial for the system to run smoothly without delayed performances or slow connection. Thus, in order to achieve this goal, three considerations must be made:

1. Make sure the implemented TCP has a mechanism for this.
2. Check the dynamic route changes of the routers to make sure that the datagrams does not dynamically change into a size that needs to be fragmented.
3. Observe the lower-level protocol headers.

The selection of the MSS is based on the need to balance competing performances and implementation issues in the transmission of data being passed around on the TCP/IP. For example, let us take the definition of overhead management into consideration. Since the TCP header takes up 20 bytes, the IP header must also use 20 bytes or more, requiring a minimum of 40 bytes to be placed for the headers. A low MSS setting would lead to an inefficient use of network bandwidth, since a larger percentage of each segment would consist of TCP and IP header information.

Conclusion needs clarification

"The likelihood of such fragmentation can be minimized by keeping the MSS as small as reasonably possible."

Why? Shouldn't it be larger, so that the computer can receive more - and then be able to handle even larger segments without the needs to fragment them? —Preceding unsigned comment added by 84.110.125.93 (talk) 05:22, 1 November 2010 (UTC)

Copyright problem removed

Prior content in this article duplicated one or more previously published sources. The material was copied from: http://searchnetworking.techtarget.com/definition/maximum-segment-size. Infringing material has been rewritten or removed and must not be restored, unless it is duly released under a compatible license. (For more information, please see "using copyrighted works from others" if you are not the copyright holder of this material, or "donating copyrighted materials" if you are.) For legal reasons, we cannot accept copyrighted text or images borrowed from other web sites or published material; such additions will be deleted. Contributors may use copyrighted publications as a source of information, but not as a source of sentences or phrases. Accordingly, the material may be rewritten, but only if it does not infringe on the copyright of the original or plagiarize from that source. Please see our guideline on non-free text for how to properly implement limited quotations of copyrighted text. Wikipedia takes copyright violations very seriously, and persistent violators will be blocked from editing. While we appreciate contributions, we must require all contributors to understand and comply with these policies. Thank you. NortyNort (Holla) 06:25, 4 June 2011 (UTC)

536, etc.

This edit caught my eye. It has been some years since I was up to speed on this stuff and really don't have time to clarify this right now. The following RFCs might be useful if anyone else wants to do this: 879, 6691, 7805; that list is probably not complete. Wtmitchell (talk) (earlier Boracay Bill) 18:38, 20 June 2019 (UTC)

Likewise I am not up to date but I reverted the IP's claim as unsourced. It sounds very unlikely. Johnuniq (talk) 23:34, 20 June 2019 (UTC)