[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BB10CB0.5090702@hp.com>
Date: Mon, 29 Mar 2010 13:25:20 -0700
From: Rick Jones <rick.jones2@...com>
To: Andi Kleen <andi@...stfloor.org>
CC: Glen Turner <gdt@....id.au>, netdev@...r.kernel.org
Subject: Re: UDP path MTU discovery
Andi Kleen wrote:
> On Mon, Mar 29, 2010 at 10:01:42AM -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.
>
>
> 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.
I don't think there are any good solutions that do not require either
application involvement, or a modification to IPv6.
How about allowing an application to request that (copies of) ICMP(v6) messages
be made available through the socket? In that way, the application, which
ostensibly already has to be keeping track of its sends for its own nefarious
retransmission porpoises can receive the "signal" just like TCP does and perhaps
there will be enough in the ICMPv6 message for the application to know which
message(s) need to be retransmitted.
rick jones
--
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