From: Wesley Eddy (email@example.com)
Date: Mon, 8 Dec 2003 16:55:21 -0500 From: Wesley Eddy <firstname.lastname@example.org> Subject: Re: tcptrace-bugs tcptrace graphing errors when window scaling in effect Message-ID: <20031208215521.GA25661@irg.cs.ohiou.edu>
On Sat, Dec 06, 2003 at 12:26:11AM +0000, email@example.com wrote:
> Hi there,
> I am using tcptrace to plot tcp connections which have the window scaling option enabled. tcptrace cannot correctly determine the true window size since the scaling factor is only exchanged at tcp session initiation and my traces do not contain the initial 3-way handshake (I realize that the scaled window is properly displayed if the initial syn-ack is present in the trace).
> This is probably more a feature request than a bug, but it would be nice if tcptrace had a command-line option which would allow a user to invoque it in 'window scaling mode' so that the resulting xplot could accurately trace the yellow line - the scaling factor couldbe passed as a parameter to tcptrace (actually, two parameters since the scaling factor can be different in each direction). This could possibly be implemented as an extended option such as:
> -w_scale_x2y z
> where x and y represent the various a2b, b2a, c2d, d2c, etc, and z is the scaling factor (for example, z=3 implies a scaling factor of 2^3, so the advertized receiver window on that connection should be multiplied by 8).
> Thanks for an awesome tool!
This is sort of an interesting case, where you're right that it's not really
a bug because if the WS bits aren't in the trace file then tcptrace can't know
to use them, and it would be easy to add a switchable default window scale
but I'm not sure it's worth it given the rarity with which it's needed. It's
only an issue in an odd set of circumstances where:
1) WS is actually used (rare)
2) SYNs aren't recorded (rare)
3) The advertised window matters more than the congestion window (hopefully
So I'm not sure if it makes more sense to just say, "you have the code, change
it" or to add yet another option to tcptrace of questionable utility ... does
anyone else on the list have an opinion? It's any easy change to make, the
question is whether it's worth it to add one more feature to the already
This archive was generated by hypermail 2.1.7 : 12/09/03 EST