Message-ID: <5DEA4E2C8262D51188B70002A55CA3C50363A709@eitrmnt106.tei.ericsson.se> From: "Gianluca Colangelo (TEI)" <Gianluca.Colangelo@tei.ericsson.se> Subject: RE: tcptrace Slow Start Duration Date: Fri, 21 Mar 2003 18:36:00 +0100
Just to give you little background behind this request, the problem concerns wireless networks. In wireless networks due to the high latency slow start can take a long time, during which the available bandwidth is under-utilized. Now being able to measure slow-start duration means also being able to tell for how long the bandwidth in under-utilized, which is a very interesting measure.
>From my experience in wireless networks the case that most frequently happens is "window-limited" and that is also the only one I would be interested in. Losses tend not to occur as buffering is used at the border between wired and wireless, the other 2 also would not be relevant to answer the question "for how long the bandwidth is under-utilised".
It would be interesting to see if a heuristic works for case 1. Surely looking at the owin graph (red line - the instantaneous one - to flatten out) it does answer my original question, provided that the dump is taken at the sender side.
Best regards,
Gianluca
> -----Original Message-----
> From: Mark Allman [mailto:mallman@grc.nasa.gov]
> Sent: marted́ 18 marzo 2003 5.10
> To: ostermann@eecs.ohiou.edu
> Cc: tcptrace@tcptrace.org
> Subject: Re: tcptrace Slow Start Duration
>
>
>
> > > * 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.
>
----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.
This archive was generated by hypermail 2b30 : 03/22/03 EST