Message-ID: <3AD20664.A19AEB39@jack.see.plym.ac.uk> Date: Mon, 09 Apr 2001 19:58:44 +0100 From: Bogdan Ghita <b.ghita@jack.see.plym.ac.uk> Subject: Re: Error in cwin estimation?
Mark Allman wrote:
>
> > 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?
I am glad you raised the issue, because, if the monitor is 'near' the
receiver, there is no way to determine cwin, and ownd will be, in most
of the cases, 2*MSS, due to delayed ACKs from the receiver. Is there any
way to go around this and determine the actual cwin?
>
> 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.
I presume you meant
ownd += ownd_sample * (time_since_last_sample / transfer_time)
It gives a nice weighting, therefore more insight, but I don't know if
it is necessary...After all, when, for example, average RTT is
determined, it is not weighted with the above term...
>
> allman
>
Bogdan Ghita
----------------------------------------------------------------------------
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