Think Thin: Thin Client and Server Based Computing Group Blog

This is a repost of an entry from ThinGuys blog.

I thought that it was important to capture it here. I have also added methods of testing this from Linux.

The Importance of MTU

<snip> One thing however that they Sun Ray does not do is fragmentation reassembly.  There are some good reasons for this as some WAN links drop fragmented packets, but mostly it's just a resource/feature issue.  But we do offer a work-around by allowing you to set the MTU on the Sun Ray itself which tells the Sun Ray protocol to throttle back on the MTU.  More on that later.

Bear with me as I step in over my head (with a little help from my friends)

One thing to consider in doing remote deployments is the Maximum Transmission Unit, which is the largest packet/datagram that can be sent over a network   In a perfect world, the MTU for ethernet is 1500.  In most WAN environments, things are far from perfect.  Due to different types of links, network gear, security features, etc, an MTU of 1500 over a WAN (and sometimes a LAN) connection is a pipe dream.  So some smart people invented PMTU Discovery, which is mechanism for a client and server to determine an agreed upon MTU.  Then some paranoid people decided to it's best to block ICMP packets across WAN routers, firewalls, etc, which basically renders PMTU-D useless.

Having the wrong MTU size is the cause for most of the frustration someone deals with in remote Sun Ray scenarios.  "Slow redraws", "jaggy", "black pixels", and "unuseable" are just some of the terms I've heard that all go away when we discover the correct MTU.   My MTU journey all started with my own dissatisfaction with my Sun Ray @ Home experience.  People were raving about it and I was just not seeing it.

So how can one find the correct MTU.  First you need a ping program that supports the do not fragment flag.

So what we want to do now is to ping through to the other side to find out the largest packet size you can get through. You can start with 1500 and work your way down until you get to one that returns without fragmenting the packet.

This example uses the Windows Ping command

C:\Documents and Settings\Craig>ping 24.234.0.7 -l 1366 -f

Pinging 24.234.0.7 with 1366 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Doh!  Santa Clara, we have a problem.  In this case 1366 is too large and I've found the 1256 is the largest size I can put through.

C:\Documents and Settings\Craig>ping 24.234.0.7 -l 1256 -f
Pinging 24.234.0.7 with 1256 bytes of data:

Reply from 24.234.0.7: bytes=1256 time=13ms TTL=59
Reply from 24.234.0.7: bytes=1256 time=18ms TTL=59
Reply from 24.234.0.7: bytes=1256 time=16ms TTL=59

Once you find your magic MTU value add/adjust option 26 on the DHCP server supplying the Sun Ray it's information, power cycle the Sun Ray and you are all set.

Here's an example for Linux:

#> ping -M do -s 1500 216.16.215.75
From 63.116.179.188 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 63.116.179.188 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 63.116.179.188 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 63.116.179.188 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 63.116.179.188 icmp_seq=1 Frag needed and DF set (mtu = 1500)

#> ping -M do -s 1366 216.16.215.75
PING bradlackey.net (216.16.215.75) 1366(1394) bytes of data.
1374 bytes from 216.16.215.75.static-cm-pool45.pool.hargray.net (216.16.215.75): icmp_seq=1 ttl=49 time=119 ms
1374 bytes from 216.16.215.75.static-cm-pool45.pool.hargray.net (216.16.215.75): icmp_seq=2 ttl=49 time=120 ms
1374 bytes from 216.16.215.75.static-cm-pool45.pool.hargray.net (216.16.215.75): icmp_seq=3 ttl=49 time=96.8 ms