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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 29 Mar 2010 10:01:42 -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

> 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.

That the IPv6 specification was heavily "influenced" by "the router guys" seems 
increasingly clear...

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