From: Grant <emailgrant@gmail.com>
To: Gentoo mailing list <gentoo-user@lists.gentoo.org>
Subject: Re: [gentoo-user] PMTUD
Date: Sun, 1 Sep 2013 03:31:10 -0700 [thread overview]
Message-ID: <CAN0CFw1-gttSL_N1aMh9QRsJDfRHEEsXLMPgDw--RbxPNXGc4w@mail.gmail.com> (raw)
In-Reply-To: <201309010937.48181.michaelkintzios@gmail.com>
>> Thanks Mick. Can you generally rely on PMTUD to set the MTU optimally
>> or should this be experimented with when changing connections?
>
> Short answer: default Linux machine settings behave properly as network
> devices and acknowledge packets larger than their MTU value with the
> appropriate response.
>
> Longer answer:
>
> Communications between IPv4 end points use PMTUD by setting a Don't Fragment
> (DF) bit in the headers of the outgoing packet. If a router/server along the
> path has a smaller MTU, it will drop that packet and respond with an ICMP
> 'Destination Unreachable -- Fragmentation Needed' packet including its smaller
> MTU value. Upon receiving this smaller packet value the initiating host will
> dynamically reduce the size of the outgoing packets, until the packet arrives
> at its intended destination. PMTUD should always be switched on in any well
> behaving network implementation, but here's the rub: some network nodes,
> firewalls, servers are configured to never respond with *any* ICMP packets
> (because they think that this is a way to avoid DDoS problems and the like).
> Therefore, the initiating host keeps sending large packets never knowing that
> they are dropped on the way. This network problem is known as a PMTUD black
> hole and is explained better here:
>
> http://tools.ietf.org/html/rfc2923
>
> Some MSWindows servers were notoriously bad at this, but I think that modern
> configurations have corrected their buggy ways. Linux machines have PMTUD
> switched on by default and behave properly.
Got it, thank you.
> If you are still troubled by the proxy connection stalling problem, have you
> tried transferring large files over the network using scp/sftp to see if you
> are also getting similar symptoms? This would isolate it to the application
> level (squid) or if the problem remains would point to network configuration
> issues.
How can I make this determination? I'm testing a 50MB scp over hotel
wifi from my laptop to the remote proxy server now (with squid running
in case it matters) and it seems OK. It oscillates constantly between
0.0KB/s and 80.0KB/s. As soon as I start browsing via the proxy
server, the upload frequently goes to "stalled" but I suppose that
could be a bandwidth issue. Browsing still stalls before very long.
- Grant
next prev parent reply other threads:[~2013-09-01 10:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-27 8:10 [gentoo-user] PMTUD Grant
2013-08-27 14:27 ` Mick
2013-09-01 7:40 ` Grant
2013-09-01 8:37 ` Mick
2013-09-01 10:31 ` Grant [this message]
2013-09-01 12:00 ` Mick
2013-09-01 12:09 ` Grant
2013-09-01 11:17 ` Grant
2013-09-01 12:57 ` Mick
2013-09-01 13:59 ` Grant
2013-09-01 15:43 ` Mick
2013-09-01 16:17 ` Grant
2013-09-01 16:53 ` Mick
2013-09-01 17:54 ` Grant
2013-09-01 18:51 ` Mick
2013-09-02 18:34 ` Grant
2013-09-02 22:29 ` Mick
2013-09-05 12:52 ` Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAN0CFw1-gttSL_N1aMh9QRsJDfRHEEsXLMPgDw--RbxPNXGc4w@mail.gmail.com \
--to=emailgrant@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox