My current host has announced they will shutdown in June, 2026. I'm
looking for suggestions for a new hosting location. Would prefer budget
oriented dedicated hosting (~$30/month). No real performance needs
(current machine is dual xeon L5640), but I'd like IPMI, two IPv4
addresses, and IPv6 would be nice. Near Seattle, WA, US preferred. Send
me an email if you have any leads.
Press start to get started. Test results will be collected.
Results
Direction
Tested Maximum Size Segment
Client Sent MSS
Notes
Server to Client IPv4
Client to Server IPv4
(n/a)
Server to Client IPv6
Client to Server IPv6
(n/a)
What is this?
This test sends packets of varying sizes from the server to your
browser, and then from your browser to the server in order to check if
Path MTU Discovery (PMTUD) is working properly between your browser and this
server; which is hopefully indicative of your experience with PMTUD in
general.
How does it work?
The first stage of the test sends varying size data packets from the
server to the browser, up to the Maxium Segment Size (MSS) sent by the
browser in the initial TCP SYN. There are three expected outcomes:
The MSS is correct, the browser can receive packets of the indicated
MSS; this server is limited to a MSS of 1460 for IPv4 and 1440 for IPv6
(MTU 1500). In this case, you should have no trouble receiving large
data packets in general.
The MSS is not correct, but the network where there MSS is
restricted does properly send ICMP Fragmentation Needed reports about
packets that are too large. In this case, you should not have trouble
receiving large data packets from servers (or peers) with properly
configured ICMP handling, but you may have trouble with servers which
don't have working ICMP.
The MSS is not correct, and ICMP Fragmentation Needed reports were
not received. In this case, you likely have trouble receiving large data
packets from many servers. However, some popular servers intentionally
use a lower MSS, and some others use probing techniques: probing may be
immediate or after a delay.
The second stage is the opposite; the browser sends varying size of
data packets to the server; packet control is less precise in this
direction, and browsers do not expose the MSS in the TCP SYN-ACK received
from the server. Again, there are three exepcted outcomes:
The browser is able to send data of any size without delay. Either
the browser received a correct MSS, or the browser does immediate
probing. Measuring the sizes of incoming packets on the server could
distinguish between these two cases, but that's not possible with normal
sockets. In either case, you should have no trouble sending large data
packets.
The browser is able to send data packets up to a certain size
without delay, but larger streams are delayed until path probing begins
and the data is sent in sizes that are able to transit the network. In
this case, you may notice some connections stall initially, but then
work fine. Repeated connections to the same server may work better, if
the server also sends large packets, receives ICMP Fragmentation Needed,
and runs a host cache that tracks that information; in that case, the
server will send a lower MSS in the SYN-ACK on connections that match
the host cache, and that will likely result in the browser sending
properly sized packets. This (FreeBSD) server has sysctl
net.inet.tcp.hostcache.enable=0 to disable the host cache, as it interferes with
probing.
The browser is able to send data packets up to a certain size
without delay, but larger streams are not received. Servers that
intentionally send a lower MSS will work fine, as long as the chosen MSS
is low enough; servers cannot initiate probing for this case. Often,
this case is visible through packet analysis on the server; smaller
packets from the client may come in fine, but MSS sized gaps often form
and are not filled in; reducing the MSS to affected networks could be
used to mitigate.
If the test completes, the summary data is sent to the server for
possible future analysis. If the test doesn't complete, please email me
Why isn't this HTTPS?
Precise packet size control is required, and that's harder, but not impossible, to do with TLS encapsulation. Maybe later.
What about IPv6?
An IPv6 test runs immediately after the IPv4 test finishes.