On Mon, Nov 10, 2008 at 1:44 AM, somebody nodoby <despista000@xxxxxxxxxxxxxx> wrote: > > Hi Peter > > I think I didn't explain properly > > my question is not about what it is slow-start but regarding where (if it) > is specified > that after filling the receive window, slow-start process has to start when > packet loss has occurred (?) > not sure what u mean.....but it sounds logical that when the received windows has filled.....packets will be dropped....and therefore slow start will start again....but then again.....there may not be only one factor involved....(eg....NewReno, see below) > In the graph I sent as a link, fast-retransmit occurs, but afterwards I > don't see fast-recovery but slow-start instead. check here for a lot of similar graphs: http://images.google.com/images?q=slow+start+tcp&um=1&ie=UTF-8&sa=N&tab=wi (which can provide hints for more research if needed....) and i think what u are looking for is in the congestion avoidance algorithm: http://en.wikipedia.org/wiki/TCP_Reno#TCP_Tahoe_and_Reno (which happened after the packets are dropped....) check this paper out: http://usenix.org/events/osdi02/tech/full_papers/venkataramani/venkataramani_html/node3.html (which describe NewReno, replacing the Reno in the wiki page above. Essentially, it is saying that to wait for a packet loss as a signature to slow down is already too late...and too expensive....so the better strategy is to measure the slowdown the round trip delays.....as a signature to slow down sending......brilliant idea) http://www.google.com/custom?domains=lkml.org&q=newreno&sa=Google+Search&sitesearch=lkml.org&client=pub-3128732077138691&forid=1&ie=UTF-8&oe=UTF-8&flav=0000&sig=IZwGi0IG8Xeqz31p&cof=GALT%3A%23008000%3BGL%3A1%3BDIV%3A%23336699%3BVLC%3A663399%3BAH%3Acenter%3BBGC%3AFFFFFF%3BLBGC%3Adde8e8%3BALC%3A0000FF%3BLC%3A0000FF%3BT%3A000000%3BGFNT%3A0000FF%3BGIMP%3A0000FF%3BFORID%3A1&hl=en (don't ask me why URL is so long.....lkml.org generated it). Due to the breath of the knowledge covered.....and my lack of background, i cannot do justice to explain the graph here.....as multiple factor may play a part....just read the recent patch....to get a feeling... source code wise, net/tcp_cong.c and net/tcp_input.c have something on NewReno inside. And this focus on congestion control: http://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf http://wand.cs.waikato.ac.nz/~iam4/papers/congestion_lca06_paper.pdf very often RFC is one thing, but implementation may be modified to workaround certain problems..... > > am I right? > > Thanks > > On Sun, Nov 9, 2008 at 3:30 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote: >> >> this is from the RFC >> >> http://www.faqs.org/rfcs/rfc2001.html >> >> (noticed how the sender/receiver window control the flow in different >> ways): >> >> The algorithm to avoid this is called slow start. It operates by >> observing that the rate at which new packets should be injected into >> the network is the rate at which the acknowledgments are returned by >> the other end. >> >> Slow start adds another window to the sender's TCP: the congestion >> window, called "cwnd". When a new connection is established with a >> host on another network, the congestion window is initialized to one >> segment (i.e., the segment size announced by the other end, or the >> default, typically 536 or 512). Each time an ACK is received, the >> congestion window is increased by one segment. The sender can >> transmit up to the minimum of the congestion window and the >> advertised window. The congestion window is flow control imposed by >> the sender, while the advertised window is flow control imposed by >> the receiver. The former is based on the sender's assessment of >> perceived network congestion; the latter is related to the amount of >> available buffer space at the receiver for this connection. >> >> The sender starts by transmitting one segment and waiting for its >> ACK. When that ACK is received, the congestion window is incremented >> from one to two, and two segments can be sent. When each of those >> two segments is acknowledged, the congestion window is increased to >> four. This provides an exponential growth, although it is not >> exactly exponential because the receiver may delay its ACKs, >> typically sending one ACK for every two segments that it receives. > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
