From: Phil Dibowitz <phil@ipom.com>
To: Krzysztof Oledzki <ole@ans.pl>
Cc: Jan Engelhardt <jengelh@computergmbh.de>,
netfilter-devel@lists.netfilter.org,
Andreas Steinmetz <ast@domdv.de>,
Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: mss to pmtu clamping partially broken?
Date: Mon, 2 Jul 2007 12:35:41 -0700 [thread overview]
Message-ID: <20070702193541.GA14961@ipom.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0707022113330.25153@bizon.gios.gov.pl>
[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]
On Mon, Jul 02, 2007 at 09:16:57PM +0200, Krzysztof Oledzki wrote:
>
>
> On Mon, 2 Jul 2007, Phil Dibowitz wrote:
>
>> On Mon, Jul 02, 2007 at 07:04:12PM +0200, Andreas Steinmetz wrote:
>>> Jan Engelhardt wrote:
>>>> Do you really need clamping? It's a hack, since TCP should do MSS
>>>> negotiation
>>>> itself. (Of course it may happen that some routers are broken.) But
>>>> usually not
>>>> for incoming packets.
>>>
>>> You never know when you hit ICMP blackholes, broken routers and other
>>> evil things. Better safe than sorry so clamping is the way to go for me.
>>
>> I encourage you to report PMTUD Blackholes to the MSS Initiative at
>> http://www.phildev.net/mss/
>
> Any chances for similar initiative for "SACK vandals"? ;)
There's already a counterpart for ECN blackholes, so I'm not opposed to it.
However, keeping up with new reports, re-testing existing offenders, etc.
takes up a good chunk of time, so I don't have the time to do it myself. I'm
happy to reference such a site, however.
Though - I'm not familiar with the problem of SACK vandals either. There
appears to be a thread on here, I'll go read it...
--
Phil Dibowitz phil@ipom.com
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Phil Dibowitz <phil@ipom.com>
To: Krzysztof Oledzki <ole@ans.pl>
Cc: Andreas Steinmetz <ast@domdv.de>,
Jan Engelhardt <jengelh@computergmbh.de>,
netfilter-devel@lists.netfilter.org,
Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: mss to pmtu clamping partially broken?
Date: Mon, 2 Jul 2007 12:35:41 -0700 [thread overview]
Message-ID: <20070702193541.GA14961@ipom.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0707022113330.25153@bizon.gios.gov.pl>
[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]
On Mon, Jul 02, 2007 at 09:16:57PM +0200, Krzysztof Oledzki wrote:
>
>
> On Mon, 2 Jul 2007, Phil Dibowitz wrote:
>
>> On Mon, Jul 02, 2007 at 07:04:12PM +0200, Andreas Steinmetz wrote:
>>> Jan Engelhardt wrote:
>>>> Do you really need clamping? It's a hack, since TCP should do MSS
>>>> negotiation
>>>> itself. (Of course it may happen that some routers are broken.) But
>>>> usually not
>>>> for incoming packets.
>>>
>>> You never know when you hit ICMP blackholes, broken routers and other
>>> evil things. Better safe than sorry so clamping is the way to go for me.
>>
>> I encourage you to report PMTUD Blackholes to the MSS Initiative at
>> http://www.phildev.net/mss/
>
> Any chances for similar initiative for "SACK vandals"? ;)
There's already a counterpart for ECN blackholes, so I'm not opposed to it.
However, keeping up with new reports, re-testing existing offenders, etc.
takes up a good chunk of time, so I don't have the time to do it myself. I'm
happy to reference such a site, however.
Though - I'm not familiar with the problem of SACK vandals either. There
appears to be a thread on here, I'll go read it...
--
Phil Dibowitz phil@ipom.com
Open Source software and tech docs Insanity Palace of Metallica
http://www.phildev.net/ http://www.ipom.com/
"Never write it in C if you can do it in 'awk';
Never do it in 'awk' if 'sed' can handle it;
Never use 'sed' when 'tr' can do the job;
Never invoke 'tr' when 'cat' is sufficient;
Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-07-02 19:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-29 11:09 mss to pmtu clamping partially broken? Andreas Steinmetz
2007-06-29 11:39 ` Patrick McHardy
2007-06-29 11:58 ` Andreas Steinmetz
2007-06-29 11:58 ` Andreas Steinmetz
2007-06-29 12:03 ` Patrick McHardy
2007-06-29 12:06 ` Andreas Steinmetz
2007-06-29 12:06 ` Andreas Steinmetz
2007-06-29 12:13 ` Patrick McHardy
2007-06-29 12:16 ` Andreas Steinmetz
2007-06-29 12:16 ` Andreas Steinmetz
2007-07-02 17:02 ` Andreas Steinmetz
2007-06-30 8:35 ` Jan Engelhardt
2007-07-02 17:04 ` Andreas Steinmetz
2007-07-02 17:04 ` Andreas Steinmetz
2007-07-02 18:28 ` Phil Dibowitz
2007-07-02 19:16 ` Krzysztof Oledzki
2007-07-02 19:16 ` Krzysztof Oledzki
2007-07-02 19:35 ` Phil Dibowitz [this message]
2007-07-02 19:35 ` Phil Dibowitz
2007-07-02 19:50 ` Krzysztof Oledzki
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=20070702193541.GA14961@ipom.com \
--to=phil@ipom.com \
--cc=ast@domdv.de \
--cc=jengelh@computergmbh.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netfilter-devel@lists.netfilter.org \
--cc=ole@ans.pl \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.