<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:10pt"><div style="font-family: times new roman,new york,times,serif; font-size: 10pt;">Lachlan/Michael,<br><br>I am not sure what "solid theory" means. There has been various heuristics for variations of SSs.<br>For instance: [1] proposes a ramp up scheme that is “less than exponential”, controlled by rtt<br>measurements, whereas [2] switches between an exponential growth to a linear one, similar to congestion avoidance, if the current window is larger than a value calculated as “the<br>pipe”. Rtt measurement based cwnd adjustment is questionable due to high variability of it on realistic network scenarios. [3] sets the ssthresh to an estimate of the session available bandwidth taken by observing the sequence of ACK arrival epochs. Another ssthresh adjustment based on available bandwidth estimate
derived from the ack stream is proposed by [4]. Although this approach<br>prevents massive packet losses during SS to CA transition if accurate bandwidth estimation is achieved, it may lead to an early departure from SS, affecting the session throughput<br>performance especially for high speed network scenarios.<br><br>We have evidence that a faster ramp-up may indeed help some transactions to complete much faster, in certain network scenarios. Unfortunately, on other scenarios, transaction completion times may be much worse than vanilla Reno...So, I am convinced that any ramp-up adjustment on Reno should be done only if favorable and adverse network scenarios can be detected automatically...<br><br>Dirceu<br><br>Dirceu<br><br>[1] C-Y. Ho, Y-C. Chan, and Y-C. Chen, “An Enhanced Slow-Start
Mechanism for TCP Vegas,” Proceedings of the 11th IEEE International
Conference on Parallel and Distributed Systems, pp. 1-7, 2005.<br>[2] R-S. Cheng, H-T. Lin, W-S. Hwang, C-K. Shieh, “Improving the<br>Ramping Up Behavior of TCP Slow Start,” Proceedings of the 19th IEEE<br>International Conference on Information Networking and Applications,2005.<br>[3] S. Giordano, G. Procissi, F. Russo, and Raffaello Secchi, “On the Use of<br>Pipesize Estimators to Improve TCP Transient Behavior,” Proceedings<br>of the IEEE International Conference on Communications - ICC2005,Vol. 1, pp. 16-20, May 2005.<br>[4] R. Wang, G. Pau, K. Yamada, M. Y. Sanadidi, and M. Gerla, “TCP<br>Startup Performance in Large Bandwidth Delay Networks,” Proceedings<br>of the IEEE 23rd Conference on Computer and Communications - INFOCOM 2004, Vol. 2, pp. 796-805, March 2004.<br><br><br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight:
bold;">From:</span></b> Michael Scharf <michael.scharf@ikr.uni-stuttgart.de><br><b><span style="font-weight: bold;">To:</span></b> Lachlan Andrew <lachlan.andrew@gmail.com><br><b><span style="font-weight: bold;">Cc:</span></b> iccrg IRTF list <iccrg@cs.ucl.ac.uk><br><b><span style="font-weight: bold;">Sent:</span></b> Monday, November 3, 2008 8:06:33 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Iccrg] Re: ADPM & incremental deployment<br></font><br>
On Mon, 03 Nov 2008 at 16:14:31, Lachlan Andrew wrote:<br>> >> [LA]: That is true if "as cautiously as it always has" is the right<br>> >> default<br>> >> behaviour. People are proposing starting slow start faster anyway,<br>> ><br>> > [BB]: Are these proposals based on any theory (not that slow start is backed<br>> > by any theory other than the 'it seems to work' theory)?<br>> <br>> Nothing quantitative that I know of. Dirceu, do you know?<br><br>[MS] Unfortunately, I am also not aware of any sound theory in this<br>field. However, there are approaches that essentially state "let's<br>start faster than slow-start only in some selected cases". As long as<br>"selected"=="few", one can assume that this is likely to work not much<br>worse than the existing slow start. And the long-tailed flow size<br>distribution might indeed help somehow.<br><br>Just my 2
cents<br><br>Michael<br><br>_______________________________________________<br>Iccrg mailing list<br><a ymailto="mailto:Iccrg@cs.ucl.ac.uk" href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br><a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a><br></div></div></div><br>
</body></html>