From: kuznet@ms2.inr.ac.ru
To: alan@lxorguk.ukuu.org.uk (Alan Cox)
Cc: roger@kea.GRace.CRi.NZ, linux-kernel@vger.kernel.org
Subject: Re: MTU and 2.4.x kernel
Date: Thu, 15 Feb 2001 22:33:23 +0300 (MSK) [thread overview]
Message-ID: <200102151933.WAA20558@ms2.inr.ac.ru> (raw)
In-Reply-To: <E14TTRF-0000Ul-00@the-village.bc.nu> from "Alan Cox" at Feb 15, 1 06:47:31 pm
Hello!
> Please cite an exact RFC reference.
No need to cite RFC, this is plain sillogism.
A. Datagram protocols do not work with mtus not allowing to send
512 byte frames (even DNS).
B. Accoutning, classification, resource reervation does not work on
fragmented packets.
-> IP suite is not full functional with low MTUs and must be eliminated.
Current setting of min_adv_mss to 536 is actually occasional.
I tested pmtu discovery on local clients using mtu 296 and did not
change the value to less fascist after this. I happened to be not
mistake, I found some fun talking to people, which suffer of superstition
that "mtu 296 is good for..." (latency for example) 8)8)8)
> to put it back together. Our handling of DF on syn frames is also broken
> due to that misassumption, but fortunately only for crazy mtus like 70.
Right observation. It stops to work even earlier: at mtu<128.
It is strict limit. Pardon, discussing marginal cases is useless.
If someone has device with mtu of 128, let him to put it back to the place,
where he found it.
Preventing DoSes requires to block pmtu discovery at 576 or at least 552.
More practical question is mtu=296. There exist old myth that this value
is good for PPP. This is nothing but myth. 14% of overhead.
I would prefer that minimal MTU on internet stayed on 576, which
is already fact.
Alexey
next prev parent reply other threads:[~2001-02-15 19:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-14 20:39 roger
2001-02-14 20:51 ` Alan Cox
2001-02-15 18:21 ` kuznet
2001-02-15 18:47 ` Alan Cox
2001-02-15 19:33 ` kuznet [this message]
2001-02-15 20:27 ` Alan Cox
2001-02-15 20:41 ` kuznet
2001-02-15 21:01 ` Alan Cox
2001-02-18 19:53 ` kuznet
2001-02-19 1:44 ` Alan Cox
2001-02-19 18:26 ` kuznet
2001-02-19 22:20 ` Rick Jones
2001-02-16 12:54 ` Rik van Riel
2001-02-18 11:26 ` Pierfrancesco Caci
2001-02-16 12:51 ` Rik van Riel
2001-02-18 19:55 ` kuznet
2001-02-18 9:39 ` David S. Miller
2001-02-18 20:17 ` kuznet
2001-02-18 20:32 ` kuznet
2001-02-15 20:40 ` Rick Jones
2001-02-15 20:54 ` Jordan Mendelson
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=200102151933.WAA20558@ms2.inr.ac.ru \
--to=kuznet@ms2.inr.ac.ru \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=roger@kea.GRace.CRi.NZ \
/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
all inboxes | Powered by JetHome®