tcp , mss selection

[sarahr202]

Hi everybody.

During TCP connection establishment, each host tells the sender how much data it is willing to receive from the sender by specifying MSS .

I was reading about how the MSS value is selected  

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

How is this MSS  determined? According to the link, two methods are used to compute mss.

Quote from the link:

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.

Then link mention 2nd method which is PMTUD.

My question is what method does the current TCP implementation use to determine MSS first method or the 2nd method i.e PMTUD?

I set up the lab in GNS3 as shown below:

client1-----ethernet----R1--------serial---------R2

Client 1 is actually a router. R2 is configured with " Ip http server".

I issue " telnet 200.200.200.2  on client1( it is the ip address of R2), and captured tcp traffic, I found Client1 and R2 choose MSS=536 ( default mss value)

thanks and have a great day.

[Rolf Fischer · Accepted solution]

Hi,

When a TCP connection is established, the end-Hosts can negotiate the initial MSS by comparing their local MTUs (Part of the 3-way handshake). This doesn't detect a possible bottleneck in the path. Here comes PMTUD into play, which is a periodic process in order to handle changes in the path.

HTH
Rolf


Sent from Cisco Technical Support Android App

[Joseph W. Doherty · Accepted solution]

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

MSS is normally determined at each host by what it believes its IP MTU is less IP and TCP overhead (normally 20 bytes for each; can be more).

Host "knows" MTU for is locally connected segment.  Host assumes that MTU might be supported end-to-end if PMTUD is active.  If not, host assumes any traffic whose destination is off the local segment wills support "Internet" size MTU.

During TCP handshake, hosts agrees to use smaller of the two hosts MSS.

If during data transfers, PMTUD is active, and a host finds it's MTU is too large, it will reduce its MTU to largest possible along the path.  (Note: this is per host as paths can be asymmetrical.)  After some time (usually 10 minutes), host will try it's max MTU to see if path MTU has changed.  (Note: this because actual paths can change, between hosts, dynamically.)

[sarahr202]

Thanks  Jose and Fischer

How does  a host determine if it has to reduce the current mss?   Because  a Packet be getting fragmented with in the network unbeknown to host.

For example:

H1----ethernet---R1-----R2-----R3----R4----ethernet---server.

H1 has chosen MSS  1460; Server has chosen 1460 too.  Both these values ensure   packets will not get fragmented on thier  local links i.e ethernet.  Let suppose the link 's mtu between R2 and R3 is 500 bytes.   H1 sends a  packet carrying  segment size 1460 in ip pay load. R2 will fragment it because of lower mtu.  R3  will reassemble the packet before sending it to server. The end result is fragmentation occurs but h1 and server do not know. Since they do not know, therefore they can not determine if they have to change mss or not.

I appreciate your help.

have a great day.

[Giuseppe Larosa · Accepted solution]

Hello Sarah,

first note:

first of all,telnet might not be the right application to test MSS negotiation, because for the interactive nature of telnet traffic, telnet packets are likely small and so I'm afraid a true MSS negotiation does not happen and they revert to use a default low value like you have seen in your tests,

PMTUD:  Path MTU Discovery works on the basis of sending appropriate probe packets with DF bit set so that if fragmentantion is needed on the path to final endpoint the router on the path sends back an ICMP too big unreachable to the original sender of the packet.

See from the link you have provided

>>Here is an example of an ICMP "fragmentation needed and DF set" message that you might see on a router after turning on >>thedebug ip icmp command:

ICMP: dst (10.10.10.10) frag. needed and DF set 
unreachable sent to 10.1.1.1

So you are right without DF bit set, the sender host cannot detect if IP fragmentation  has happened on the path to the final destination.

As noted by Joseph and Fischer the PMTUD is a dynamic process and the test is repeated over time to dynamically adapt to changes in the path.

Hope to help

Giuseppe

[sarahr202]

Thanks Giuseppe. ( long time no see)

I understand now how fragmentation can  be be avoided with the help pmtud. The question is how does PMTUd do it?

Based on the link this i what I understand.

H1------Ethernet----R1-------R2----mtu 500--R3---ethernet--server

For simplicity please consider the packet flow from H1 to server only.

   Let suppose the initial MSS is 1460 at both host1 and server and pmtud is active.

Let say H1 sends a packet with mss=1460. to server.

1)Will PMTUD process at host set DF bit in ip header  and wait  to see if it receives any ICMP message?  If pmtud process receives an icmp, it will  set the MSS to a lower value? Pmtud  will keep doing  this until it no longer receives any ICMP.  Is my understanding correct?

2)Does it mean all packets from H1 will have DF bit set? or does it mean everytime PMTUD wants to check the lowest mtu from h1 to server, PMTUD will set the DF bit so only those packets will have DF bit set not all.?

===============================================================================

3)  Let say host1 and server just establishe a new tcp connection with each choosing initial mss 1460 and PMTUD is active.

Host1 sends the first tcp segment after establishing TCP connection. Will PMTUD set the DF bit for this very first tcp segment? Or simply put does PMTUD always set the "DF" bit for the the first packet going to a destination after the tcp connection is established? 

Thanks and have a great day.

thanks and have a great day.

[Joseph W. Doherty · Accepted solution]

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

To clarify a bit, TCP doesn't support fragmentation, IP does.

To avoid fragmentation, TCP attempts to set its MSS so fragmentation will be avoided.

PMTUD depends on df (don't fragment) bit set on IP packets.

Any L3 hop, that receives a packet that's larger than its outgoing MTU looks at the df bit.  If not set, it fragments the IP packet and forwards the fragments.  If df bit is set, it drops the packet and sends a message back to the sender the packet was too large (or needs fragmentation).  Originally, sender was only informed packet was too large (then sender had to find maximum MTU by trial and error.)  Newer implementations will also include in message what the maximum MTU is (avoids the need for trial and error).

When sender receives the too large message, it reduces its MTU to that destination.  As I noted before, after some time, sender will try full size MTU to determine if MTU restriction is still in place.

One major issue, for whatever reason, if sender doesn't get too large notification, it will keep sending full size and those packets will keep being dropped.  (Often this results in "odd" behavior, for example, you can log onto a FTP server, issue get/put commands, but then a file with more than max MTU data can't be transferred.)

Systems that don't support the newer how large notification will work, but they take much longer to recover (as they have to find the maximum).

[sarahr202]

Great  answer. Thanks for your help and patience.