From owner-freebsd-net@FreeBSD.ORG Thu Jan 8 03:55:34 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D817E16A4D0 for ; Thu, 8 Jan 2004 03:55:34 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id B18CB43D5A for ; Thu, 8 Jan 2004 03:55:32 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 3817 invoked from network); 8 Jan 2004 11:55:31 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Jan 2004 11:55:31 -0000 Message-ID: <3FFD4533.A35B6CD0@freebsd.org> Date: Thu, 08 Jan 2004 12:55:31 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rw@codeburst.co.uk References: <200401080202.CAA20485@starburst.demon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: kern/60889 - zero IP id change issues in 5.2RC2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 11:55:35 -0000 Richard Wendland wrote: > > 5. Random ip_id is already a kernel option but it is *not* enabled by > > default in 5.2RC2 GENERIC or -current. > > I don't think random ip_id should be enabled by default. The reduction > in ip_id cycle from 64k is a real re-assembly risk on modern high-speed > networks. Random ip_id brings debatable benefits. There was a good > discussion about this on tech-net@NetBSD.org last November, where they > rejected random ip_id as default. Ok. > One issue is that they (claim to have) discovered the OpenBSD random > ip_id code has a 12k cycle rather than the advertised 30k: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0005.html > http://mail-index.netbsd.org/tech-net/2003/11/27/0007.html > > The other is a consideration of what the maximum safe data transfer rate > is for a given ip_id cycle. You want long ip_id cycle times for non-DF > gigabit networking, like NFS. I buy into these arguments by Robert Elz > and Jonathan Stone: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0013.html > http://mail-index.netbsd.org/tech-net/2003/11/26/0015.html > > though a good contrary view is: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0021.html Haven't read all of that yet. > It's important to remember that if fragmentation takes place, and a > fragment is lost, the other fragment(s) will wait for quite some time in > a re-assembly buffer (maybe up to 63 seconds). While they are waiting > they are at quite some risk of being joined onto a fragment from the > next ip_id cycle if a lot of packets are flowing: > > http://mail-index.netbsd.org/tech-net/2003/11/26/0022.html > http://mail-index.netbsd.org/tech-net/2003/11/26/0023.html > > Remember a 64k cycle is consumed by 64MB of transfer if average datagram > size is 1024 bytes. Thats not a lot on a gigabit network. > > The better solution in my opinion is to do similar to Solaris, have > per-destination ip_id counters (or at least a hash of destination IP > to one of N ip_id counters). You typically get longer cycle times and > improved privacy, with a method that is faster than random ip_id. I have an idea how to something like this in an efficient manner. Have a global incrementing ip_id counter and a small fixed size hash table. The hash is computed from faddr/fport (see tcp_hostcache for a good hash function). The hash table contains seeds in every bucket which are refreshed periodically (every second or ten or whatever). For an outgoing packet you take the global ip_id counter, increment it by one, take the result and XOR it with the seed in the apropriate bucket. The chance of collisions is very low and you get the full 64k cycle (globally). Or you can do it the other way around and have a counter in every bucket and a global seed. Need to think about which is actually better. -- Andre