FAQ 165 reads in part (well, "in most"):
If you can update with smaller entries, but not long ones, there is most likely a problem with your computer's MTU (maximum transmission unit) limit. This is most commonly found when your computer is set up to share an Internet connection with another computer in the house, or if you have a firewall on your computer.I think we can be more helpful and clearer there. How about something along the lines of
LiveJournal can't help you resolve the problem; you will need to contact your network administrator or consult your operating system's help files.
If you can update with smaller entries, but not long ones, your computer's MTU (Maximum Transmission Unit, the maximum amount of data that can be sent in one packet over your network) may be set too high. This situation is most commonly found when your computer is set up to share an Internet connection with another computer in the house, or if you connect to your Internet provider over PPPoE (PPP over Ethernet, common on ADSL connections).The problem, essentially, is roughly this: The client computer has an MTU of, say, 1500. That travels fine over Ethernet, but if they are using something that has to encapsulate the packets -- say, PPPoE or a VPN -- then they can creep larger than 1500 bytes. When that happens, the next hop has to fragment the packets, which slows things down, sometimes even noticeably. But that's the good scenario -- in the bad (and most common) scenario, the packets get set with the Don't Fragment (DF) bit set. Then the next hop receives them, sees they're too large to send unfragmented, sees it can't fragment them, and just discards them. That hop thus acts as (and is called) a "black hole route".
LiveJournal can't help you resolve the problem; if you cannot resolve it yourself you will need to contact your Internet service provider or network administrator, or consult the documentation for your operating system.
Too low an MTU cannot cause the problem the FAQ describes, (although it can slow things down itself because of packet reassembly overhead), and users won't necessarily grasp what values are canonically problematic and which are sensible for their situation, so "lower" is an important hint.
I can't think of a scenario where a firewall, software or black-box, could introduce MTU problems without also encapsulating, so I replace the firewall reference with a PPPoE reference, which is the most common scenario for MTU problems.
Other changes: mention ISP before network administrator, since people will probably encounter this at home rather than in an office or school, and include those operating systems that don't have "help files". :-)
I would also really, really recommend linking to the dslreports FAQ on MTU tuning, since it provides step-by-step instructions on how to set your MTU. I realize external links are rare (but not nonexistent) in the FAQ, but there's a lot of dumb advice on the Web about MTU settings, and the dslreports FAQ is one exception to that.