Message-Id: <200303171550.KAA08722@lawyers.ir.bbn.com> From: Mark Allman <mallman@grc.nasa.gov> Subject: Re: tcptrace Slow Start Duration Date: Mon, 17 Mar 2003 10:50:12 -0500
(First, all of this assumes sender-side traces.)
> It's generally pretty easy to deduce by looking at the time sequence
> graph (-S). Printing the value out numerically would require a
> heuristic.
Yes.
> I imagine that you could watch the outstanding data (sent but not
> ACKed; a good estimator of congestion window) and look for it to
> "flatten out". Alternately, you could try to match outgoing
> segments with incoming ACKs and watch for a 1-to-1 correspondence
> to start, but that's an even less robust heuristic.
I think the heuristic is easier, actually...
* Watch for a retransmit, which should signal the end of slow
start.
* Watch for the connection to become window limited (i.e., the
cwnd == advertised window).
Clearly that assumes a good RFC2581 compliant TCP -- which might be
a big assumption. I suppose that in the end I am pretty dubious of
adding these sorts of things to tcptrace (which I see as a really
nice tool for reporting what can be seen on the wire, not trying to
deduce a whole lot else).
allman
-- Mark Allman -- NASA GRC/BBN -- 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 : 03/18/03 EST