Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Mar 2003 20:20:27 -0500
From:      Jim Bloom <bloom@acm.org>
To:        "Crist J. Clark" <cjc@FreeBSD.ORG>
Cc:        Wiktor Niesiobedzki <w@evip.pl>, freebsd-ipfw@FreeBSD.ORG
Subject:   Re: Prioritizing empty TCP ACKs with ipfw?
Message-ID:  <3E77C5DB.40202@acm.org>
In-Reply-To: <20030318200828.GC74853@blossom.cjclark.org>
References:  <20030314085636.GB64326@galgenberg.net> <el59ycqr.fsf@ID-23066.news.dfncis.de> <20030314224655.GA2616@mail.evip.pl> <20030318200828.GC74853@blossom.cjclark.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E77C5DB.40202>