Message-Id: <200104091633.MAA07877@guns.lerc.nasa.gov> From: Mark Allman <mallman@grc.nasa.gov> Subject: Re: Error in cwin estimation? Date: Mon, 09 Apr 2001 12:33:50 -0400
> The number of ACKs is higher than the number of cwin calculations,
> at least if we consider the retransmissions and the SYN and FIN
> sequences. Should there be another variable (yet another one :-)
> ), such as cwin_count, that is incremented each time cwin_tot is
> updated?
Ouch. I think a new variable is needed. But...
So, let me revisit an issue about the "average CWIN" (being the
person responsible for requesting this metric). Err... Two issues:
First, "CWIN" is a Very Poor name. The number is not the congestion
window, it is the amount of outstanding data. There are cases when
there is no distinction and cases where there is quite a bit of
difference. It is false advertising to call this cwin. But, that
is more of a rant than an issue. The issue is what should the
"average ownd" be?
It seems to me that the average ownd should depend on time. As a
contrived example, consider 5 ownd data points: 2000, 4000, 6000,
6500, 7000 bytes. The average (sum/5) ownd is 5100 bytes according
to your code (assuming a fix for the example ACK problem). But,
think about the following measurements and when they were taken.
time ownd
---------
0.0 2000
10.0 4000
10.1 6000
10.2 6500
10.3 7000
10.4 done
Clearly for most of the connection we used an ownd of 2000 bytes.
So, one could argue that characterizing the "average" ownd as 5100
bytes is busted. I think we should use something like:
ownd += ownd_sample + (time_since_last_sample / transfer_time)
for each sample taken. In the above case this leads to something on
the order of 2149 bytes -- which I would argue is a much better
characterization of the connection than the current code yields.
allman
-- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/ ---------------------------------------------------------------------------- To unsubscribe, send a message with body containing "unsubscribe tcptrace" to majordomo@tcptrace.org.
This archive was generated by hypermail 2b30 : 04/10/01 EDT