| 1 |
>> Thanks Mick. Can you generally rely on PMTUD to set the MTU optimally |
| 2 |
>> or should this be experimented with when changing connections? |
| 3 |
> |
| 4 |
> Short answer: default Linux machine settings behave properly as network |
| 5 |
> devices and acknowledge packets larger than their MTU value with the |
| 6 |
> appropriate response. |
| 7 |
> |
| 8 |
> Longer answer: |
| 9 |
> |
| 10 |
> Communications between IPv4 end points use PMTUD by setting a Don't Fragment |
| 11 |
> (DF) bit in the headers of the outgoing packet. If a router/server along the |
| 12 |
> path has a smaller MTU, it will drop that packet and respond with an ICMP |
| 13 |
> 'Destination Unreachable -- Fragmentation Needed' packet including its smaller |
| 14 |
> MTU value. Upon receiving this smaller packet value the initiating host will |
| 15 |
> dynamically reduce the size of the outgoing packets, until the packet arrives |
| 16 |
> at its intended destination. PMTUD should always be switched on in any well |
| 17 |
> behaving network implementation, but here's the rub: some network nodes, |
| 18 |
> firewalls, servers are configured to never respond with *any* ICMP packets |
| 19 |
> (because they think that this is a way to avoid DDoS problems and the like). |
| 20 |
> Therefore, the initiating host keeps sending large packets never knowing that |
| 21 |
> they are dropped on the way. This network problem is known as a PMTUD black |
| 22 |
> hole and is explained better here: |
| 23 |
> |
| 24 |
> http://tools.ietf.org/html/rfc2923 |
| 25 |
> |
| 26 |
> Some MSWindows servers were notoriously bad at this, but I think that modern |
| 27 |
> configurations have corrected their buggy ways. Linux machines have PMTUD |
| 28 |
> switched on by default and behave properly. |
| 29 |
|
| 30 |
Got it, thank you. |
| 31 |
|
| 32 |
> If you are still troubled by the proxy connection stalling problem, have you |
| 33 |
> tried transferring large files over the network using scp/sftp to see if you |
| 34 |
> are also getting similar symptoms? This would isolate it to the application |
| 35 |
> level (squid) or if the problem remains would point to network configuration |
| 36 |
> issues. |
| 37 |
|
| 38 |
How can I make this determination? I'm testing a 50MB scp over hotel |
| 39 |
wifi from my laptop to the remote proxy server now (with squid running |
| 40 |
in case it matters) and it seems OK. It oscillates constantly between |
| 41 |
0.0KB/s and 80.0KB/s. As soon as I start browsing via the proxy |
| 42 |
server, the upload frequently goes to "stalled" but I suppose that |
| 43 |
could be a bandwidth issue. Browsing still stalls before very long. |
| 44 |
|
| 45 |
- Grant |
Archives