Friday 22 July 2016

Path Maximum Transmission Unit Discovery

Path Maximum Transmission Unit Discovery


Path maximum transmission unit (PMTU) discovery is a method for dynamically learning the maximum transmission unit of any Internet channel. The discovered PMTU is used by the TCP or UDP layer to create packets of an optimum size for that channel. This avoids fragmentation overhead on the routers in the path, and reassembly overhead on the receiving server.

PMTU discovery is an operational mode in the NetScaler. This mode enables the NetScaler to interoperate with other routers participating in PMTU discovery. In a typical topology, the NetScaler is deployed in front of the servers it manages, and either manages connections from clients on behalf of these servers (transparent mode), or manages connections with the servers and clients independently (endpoint mode).

The NetScaler in Transparent Mode


In transparent mode, if a managed server sets the DF bit and sends a datagram, and Path MTU is smaller than the size of the datagram, the NetScaler receives an ICMP error. When the NetScaler is operating in MIP mode, it adjusts the MTU to the MIP and updates the MTU database so that the lower MTU is used for subsequent connections. All packets subsequently sent via that connection have the DF bit unset.

In USIP mode, when an ICMP error message is received, the NetScaler translates it and sends it to the managed server. The managed server updates the MTU for that destination, and subsequent datagrams are sent with the lowered MTU. The MTU value for that client is also updated in the NetScaler. All new connections then use the lowered MTU.

The NetScaler in End-Point Mode


In end-point mode, the NetScaler separately manages connections to the servers it manages and connections to the clients that contact those servers.

For client connections, the NetScaler uses an Maximum Segment Size (MSS) of 1460 bytes. If the network contains a router that fragments the packet into multiple datagrams because of MTU mismatches, the router sends an ICMP error to the NetScaler. The NetScaler does not pass the error to the servers it manages,  but parses it and determines an MTU appropriate for that particular client. The NetScaler then updates the MTU database with the lower MTU. Thereafter, it uses the new MTU value for all new connections to that client.

Enabling or Disabling PMTU Discovery


The NetScaler does not participate in PMTU Discovery by default.

To enable or disable PMTU discovery using configuration utility

1. In the Navigation Pane, expand System, and then click Settings.
2. On the Settings page, under Modes & Features click Change modes.
3. In the Configure Modes dialog box, select the Path MTU Discovery check box to enable this feature, or clear the check box to disable it, and click OK

To enable or disable PMTU discovery using using the NetScaler command line

At the NetScaler command prompt, type:
enable ns mode PMTUD
or
disable ns mode PMTUD

Configuring TCP Window Scaling


The TCP window scaling option increases the TCP receive window size beyond its maximum value of 65,535 bytes. This TCP option is defined in RFC 1323. The window scaling option is required for efficient transfer of data over long fat networks (LFNs).

A TCP window determines the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before receiving any acknowledgment from the receiver. The main purpose of the window is flow control.

The window size field in the TCP header is 16 bits, which limits the ability of the sender to advertise a window size larger than 65535 ( 2^16 - 1). The TCP window scale extension expands the definition of the TCP window to 30 bits by using a scale factor to carry this value in the 16 bit window field of the TCP header. In the NetScaler, the window scale expands the definition of the TCP window to 24 bits. The scale factor is carried in the new TCP window scale field. This field is sent only in a SYN packet (a segment with the SYN bit on).

The new window size is calculated by the receiver.
[right shifting the bits of the received window size by the scale factor value]

which is equivalent to
[(2^scale factor) * received window size]

Before configuring window scaling, make sure that:

• You do not set a high value for the Scale Factor, because this could have adverse effects on the NetScaler and the network.
• You have enabled SACK (selective acknowledgement).
• You do not configure window scaling unless you clearly know why you want to change the window size.
• Both hosts in the TCP connection send a window scale option during connection establishment. If only one side of a connection is sets this option, windows scaling will not be used for the connection.
• Each connection for same session (such as TCP session between Client and NetScaler and TCP session between NetScaler and Server having the same request/response) is an independent Window Scaling session. It is possible to have window scaling between the client and a Citrix NetScaler and not the a Citrix NetScaler and a server.

1 comment:

  1. Your concepts were easy to understand that I wondered why I never looked at it before. Thank you for this blog. This is very interesting and useful.REad more CNS 220

    ReplyDelete