Date: Thu, 07 Feb 2008 10:10:49 +0100 From: Andre Oppermann <andre@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: cvs-src@FreeBSD.org, Mike Silbersack <silby@FreeBSD.org>, "Bruce M. Simpson" <bms@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet ip_id.c Message-ID: <47AACB19.9040203@freebsd.org> In-Reply-To: <20080207083930.Y74369@fledge.watson.org> References: <200802061540.m16FeXGD030782@repoman.freebsd.org> <47AA5925.3000008@FreeBSD.org> <20080207083930.Y74369@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > On Thu, 7 Feb 2008, Bruce M. Simpson wrote: > >> Mike Silbersack wrote: >>> Note that this commit does not yet enable random IP ID >>> generation by default. There are still some concerns >>> that doing so will adversely affect performance. >> >> Random ip_id generation also breaks MANET multicast as it's currently >> specified -- the ip_id field gets used for histogram based duplicate >> packet detection. However, after my inveigling, Fred Templin at Boeing >> brought encapsulation back into the proposal on the table. >> >> So some way to turn this stuff off on a per-interface basis is >> probably going to be needed later on for mobile stuff... > > We also have much more general problems with our ip_id code -- using a > global IP ID counter or random generator breaks down as the packet rate > goes up, causing problems for NFS over UDP and other UDP applications > with large packet sizes. We need to adopt some sort of host-based > approach, presumably with a fallback to global when we don't want to > commit state storage for a host (i.e., for RST's/SYN cookies, or even > TCP generally). There's a comment in the Linux IP ID code regarding > PPTP also expecting IP IPs to behave in a more historical way as well. A sufficiently good hash algorithm should be able to replace storage allocation and tracking per host. This way we have an IPID sequence space per hash bucket where we can guarantee a full cycle. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47AACB19.9040203>