netdev - Re: UDP path MTU discovery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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