Message-Id: <200303180410.XAA11399@lawyers.ir.bbn.com> From: Mark Allman <mallman@grc.nasa.gov> Subject: Re: tcptrace Slow Start Duration Date: Mon, 17 Mar 2003 23:10:17 -0500
> > * Watch for a retransmit, which should signal the end of slow
> > start.
>
> Unless you become window limited first. Which is still common in
> my experience. Whether that's true or not, we get to your next
> point...
>
> > * Watch for the connection to become window limited (i.e., the
> > cwnd == advertised window).
>
> Yes. I'm concerned that this heuristic isn't as obvious as I
> would like. Making sure that the observed window is within a MSS
> of the advertisement would be a start.
I think that would actually work pretty well.
> I'm concerned that in many traces that I've seen, the tracing
> point (while "near" the sender) is just enough farther away that
> it's clear in the traces that the connection has become window
> limited even though we're technically not near enough the
> advertised window.
So, there are all sorts of things that tcptrace both measures well
and measures really poorly depending on your vantage point. I am
not sure I understand the pushback on this point for the duration of
slow start.
(That's not a vote in favor of it, it's a wondering on what sorts of
things make the cut.)
> That being said, however, I've been toying with a heuristic of
> trying to characterize a connection into:
>
> 1) window limited
> (as above)
> 2) loss-limited
> (high amount of retransmission)
> 3) normal
> (or can't tell?)
> 4) data limited
> (not enough application data)
Look at tcpevel (Crovella & Barford - SIGCOMM ~2000). You can do
these sorts of things if you're **very** careful.
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