From: Andi Kleen <andi@firstfloor.org>
To: Glen Turner <gdt@gdt.id.au>
Cc: Rick Jones <rick.jones2@hp.com>, Andi Kleen <andi@firstfloor.org>,
netdev@vger.kernel.org
Subject: Re: UDP path MTU discovery
Date: Thu, 1 Apr 2010 02:55:39 +0200 [thread overview]
Message-ID: <20100401005539.GZ20695@one.firstfloor.org> (raw)
In-Reply-To: <1270078984.2389.33.camel@ilion>
On Thu, Apr 01, 2010 at 10:13:04AM +1030, Glen Turner wrote:
> On Mon, 2010-03-29 at 10:01 -0700, Rick Jones wrote:
>
> > But which of the last N datagrams sent by the application should be retained for
> > retransmission? It could be scores if not hundreds of datagrams depending on
> > the behaviour of the application and the latency to the narrow part of the network.
>
> We don't need that sort of exotica from the kernel. The applications
> have to be prepared to retransmit lost packets in any case.
>
> What we need is an API for an instant notification that a ICMP Packet
> Too Big message has arrived concerning the socket.
That already exists of course: IP_RECVERR
> As for David Miller's rant, the applications currently have no choice
> but to "do it stupidly" as the kernel doesn't pass enough information
> for user space to do it intelligently. If the kernel passed user space
> the same indication as TCP gets, then we could -- and would -- do it
> right.
That's wrong. Linux has supported UDP/RAW pmtu discovery since many many
years.
I have a really old presentation on it (from 2000 or so):
http://halobates.de/net-topics/text33.htm
http://halobates.de/net-topics/text34.htm
http://halobates.de/net-topics/text35.htm
http://halobates.de/net-topics/text36.htm
It's also in the manpages.
However I suspect it's too much work to change a lot of applications
to that, so I suspect the IPV6_MIN_MTU workaround is still needed.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-04-01 0:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 0:02 UDP path MTU discovery Glen Turner
2010-03-26 0:53 ` Rick Jones
2010-03-26 3:26 ` David Miller
2010-03-26 17:48 ` Rick Jones
2010-03-31 23:42 ` Glen Turner
2010-03-31 23:51 ` Hagen Paul Pfeifer
2010-04-01 0:06 ` Rick Jones
2010-03-26 3:24 ` David Miller
2010-03-28 8:41 ` Andi Kleen
2010-03-31 23:57 ` Glen Turner
2010-04-01 0:57 ` Andi Kleen
2010-03-28 8:50 ` Andi Kleen
2010-03-29 17:01 ` Rick Jones
2010-03-29 20:14 ` Andi Kleen
2010-03-29 20:25 ` Rick Jones
2010-03-29 20:50 ` Edgar E. Iglesias
2010-03-29 21:01 ` Rick Jones
2010-03-29 21:29 ` Eric Dumazet
2010-03-29 23:38 ` Templin, Fred L
2010-03-30 5:20 ` Andi Kleen
2010-03-30 6:06 ` Eric Dumazet
2010-03-30 6:16 ` Andi Kleen
2010-03-30 6:17 ` UDP path MTU discovery II Andi Kleen
2010-03-30 6:16 ` UDP path MTU discovery Edgar E. Iglesias
2010-03-30 6:19 ` Andi Kleen
2010-03-30 8:20 ` Edgar E. Iglesias
2010-03-30 14:12 ` Andi Kleen
2010-03-30 22:04 ` Edgar E. Iglesias
2010-03-30 15:58 ` Templin, Fred L
2010-03-30 16:06 ` Andi Kleen
2010-03-31 23:43 ` Glen Turner
2010-04-01 0:55 ` Andi Kleen [this message]
2010-04-02 5:41 ` Glen Turner
2010-04-04 10:25 ` Andi Kleen
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=20100401005539.GZ20695@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=gdt@gdt.id.au \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
/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;
as well as URLs for NNTP newsgroup(s).