Re: [tcpm] I-D Action:draft-ietf-tcpm-tcp-auth-opt-01.txt

On Thursday 17 July 2008, Adam Langley wrote:
> On Wed, Jul 16, 2008 at 5:25 PM, Stefanos Harhalakis <v13@v13.gr> wrote:
> > Apart from that, I believe that you (we) should fill a bug report.
>
> Well, since I was the last person to rewrite the options code in
> Linux(*), you might as well tell me here :)
>
> I'm not sure exactly what the issue is here. There isn't excessive
> padding: 99.9% of packets have only a timestamp option and thus have
> the minimal amount of padding. The advantage of writing/reading
> aligned data outweighs better compaction in SYN frames since there's
> (currently) no options that we excluded because of the padding.

There are not many more things to report that those discussed in the list:
* The ability to store more options when necessary
* 4 bytes of extra space for data when TSs and SACKs are included
* 4xN less bytes transmitted over the network in each session (where N is the 
number of segments with TS+SACK that are sent)

>From a very sallow test/accounting I've just performed (1 minute run) on a 
linux firewall for a not so large, not congested network, it seems that about 
3-4% of the TS segments also include a SACK header and that there could be 
saved about 1 byte every 7-8 TS-enabled segments (not counting SYN segments).

Sample results:

ts: 7497, tssack: 255, noop: 1020
ts: 8133, tssack: 347, noop: 1388
ts: 7295, tssack: 270, noop: 1080
ts: 7030, tssack: 265, noop: 1060
ts: 7162, tssack: 234, noop: 936
ts: 7328, tssack: 294, noop: 1176

1st column is segments with TS, second is segments with TS+SACK (also counted 
in first column), third column is SUM(floor(NOOP_count/4)*4) (number of bytes 
that where transmitted as NOOP and could be saved (only counts 32 bit 
words)).

Is it worth?
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm