Message-Id: <200104091924.PAA09613@guns.lerc.nasa.gov> From: Mark Allman <mallman@grc.nasa.gov> Subject: Re: Error in cwin estimation? Date: Mon, 09 Apr 2001 15:24:32 -0400
> 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?
Maybe... There is an algorithm in the following paper that tracks
the segments that are liberated by a given ACK during slow start.
Mark Allman, Vern Paxson. On Estimating End-to-End Network Path
Properties. ACM SIGCOMM, September 1999, Cambridge, MA.
http://roland.grc.nasa.gov/~mallman/papers/estimation.ps
My *guess* is that with some elbow grease you might be able to use
that during both slow start and congestion avoidance to estimate the
amount of outstanding data. But, that is just a guess.... I don't
think it is a trivial extension.
> I presume you meant
> ownd += ownd_sample * (time_since_last_sample / transfer_time)
Yep.
> 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...
True.
However, the RTT, unlike the cwnd, is a property of the network
path. So, we can't assume that the RTT is static between samples as
the cwnd is.
Maybe just two ways of looking at things...
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