[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100329205035.GA32656@laped.iglesias.mooo.com>
Date: Mon, 29 Mar 2010 22:50:35 +0200
From: "Edgar E. Iglesias" <edgar.iglesias@...il.com>
To: Andi Kleen <andi@...stfloor.org>
Cc: Rick Jones <rick.jones2@...com>, Glen Turner <gdt@....id.au>,
netdev@...r.kernel.org
Subject: Re: UDP path MTU discovery
On Mon, Mar 29, 2010 at 10:14:31PM +0200, Andi Kleen wrote:
> On Mon, Mar 29, 2010 at 10:01:42AM -0700, Rick Jones wrote:
> > >In theory one could probably add some hack in the the kernel UDP code
> > >to hold one packet and retransmit it immediately with fragments when
> > >the ICMP comes in. However that would be quite far in behaviour from
> > >traditional UDP and be considered very ugly. It could also mess up
> > >congestion avoidance schemes done by the application.
> > >
> > >Still might be preferable over rewriting zillions of applications?
> >
> > 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.
>
> Yes, if there's a large window you lose. I guess it would make protocols
> like DHCP work at least ("transactional UDP" as the original poster called it)
>
> I don't know if it would fix enough applications to be worth
> implementing. The only way to find out would be to try I guess.
> I don't have any better ideas.
>
> > That the IPv6 specification was heavily "influenced" by "the router guys"
> > seems increasingly clear...
>
> Yes it sounds like the IETF didn't completely think that through.
Are things really that bad?
These "transactional" IPv6 apps all have the option to stick to 1280
sized datagrams to avoid the problem. If throughput is an issue these
apps will surely benefit from proper PMTUD anyway or?
Cheers
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists