From owner-freebsd-ipfw Tue Mar 18 17:21:18 2003 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D11737B404; Tue, 18 Mar 2003 17:21:17 -0800 (PST) Received: from jbloom.org (reyim.ne.client2.attbi.com [24.60.104.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03D9243F3F; Tue, 18 Mar 2003 17:21:16 -0800 (PST) (envelope-from bloom@acm.org) Received: from acm.org (jmblap.jbloom.org [172.17.235.110]) by jbloom.org (8.12.8/8.12.7) with ESMTP id h2J1KZli066614; Tue, 18 Mar 2003 20:20:36 -0500 (EST) (envelope-from bloom@acm.org) Message-ID: <3E77C5DB.40202@acm.org> Date: Tue, 18 Mar 2003 20:20:27 -0500 From: Jim Bloom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Crist J. Clark" Cc: Wiktor Niesiobedzki , freebsd-ipfw@FreeBSD.ORG Subject: Re: Prioritizing empty TCP ACKs with ipfw? References: <20030314085636.GB64326@galgenberg.net> <20030314224655.GA2616@mail.evip.pl> <20030318200828.GC74853@blossom.cjclark.org> In-Reply-To: <20030318200828.GC74853@blossom.cjclark.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Crist J. Clark wrote: > The amount of data in any given TCP segment is not stored explicitly > in the header. It has to be calculated by, > > segment_data_length = ip_datagram_len - ip_header_len - tcp_offset > > Given that an IP header is almost always 20-bytes long and the TCP > header (offset) is usually 20-bytes, your value makes sense... Unless > the TCP header is carrying options, e.g. timestamps. > > Doing this calculation would be easy enough, but I think your solution > is probably sufficient. If any change were to be made, I think > changing the 'iplen' option to do "greater-than" and "less-than" > checks, rather than just "equals" would be more useful in > general. That way, you can catch ACKs with no data, but ones that also > have a timestamp option (<53), or sack options (<53, <61, or <68, > depending on how many you want to allow). If the 'iplen' option is set in the 50-70 range to handle other options in the packet, it will also help interactive response for terminal emulation. Typing and character echo usually send a few bytes of data at a time. Jim Bloom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message