Date: Mon, 17 Mar 2003 21:40:05 -0500 From: Joseph Ishac <jishac@grc.nasa.gov> Subject: Re: tcptrace Slow Start Duration Message-ID: <20030317214005.A22431@sunfire.grc.nasa.gov>
On Mon, Mar 17, 2003 at 06:11:42PM -0500, Shawn Ostermann wrote:
> 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)
>
> This would answer a common question among many people, "why is this
> connection so slow"?
>
> My first though is to characterize, separately, each RTT window and
> group each flight into one of the above. Then to see if there's enough
> agreement between the intervals to declare an overall behavior.
I'm not sure I follow. My take is that it is a combination of the
above, plus other factors that yield a connections overall behavior.
(Well, except "normal" I'm not sure what a "normal" connection is :)
Also, "so slow" would need defining, and that's not clear either. I
guess an example that comes to mind is a data limited connection that
suffers from several RTO's (say from the lack of being able to generate
enough dupacks). In that case, you would see windows of "data limited"
transfers and windows of "loss-limited" transfers (if I'm following your
outline above correctly). Same goes for window limited and losses. For
long (>several flights) I see the characterization becoming rather
'difficult'. It may be an interesting analysis for short transfers
(<several flights), but I'd need convincing :)
Regardless, this doesn't seem like a job for tcptrace. (If the intent
was to add it to tcptrace).
-Joseph
----------------------------------------------------------------------------
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