<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The problem is that "elevated RTT" doesn't necessarily mean a lot. Consider <a href="ftp://ftpeng.cisco.com/fred/RTT/index.html">ftp://ftpeng.cisco.com/fred/RTT/index.html</a>.<div><br></div><div><a href="ftp://ftpeng.cisco.com/fred/RTT/Pages/2.html">ftp://ftpeng.cisco.com/fred/RTT/Pages/2.html</a> shows the picture you are expecting. Delay is temporarily increased because there is a file transfer happening. In such a case it might make sense.</div><div><br></div><div><a href="ftp://ftpeng.cisco.com/fred/RTT/Pages/3.html">ftp://ftpeng.cisco.com/fred/RTT/Pages/3.html</a> and <a href="ftp://ftpeng.cisco.com/fred/RTT/Pages/6.html">ftp://ftpeng.cisco.com/fred/RTT/Pages/6.html</a> show cases of a sustained change in delay due to some shift in underlying routing. In such cases, or at least the former, dropping because delay appears to be high will have to reducing your window ad infinitum with no valuable effect.</div><div><br><div><div>On Feb 20, 2009, at 10:53 AM, Saverio Mascolo wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">the idea of consider a packet loss as due to congestion IF and ONLY IF it happens in the presence of inflated rtt is always appealing even though not new anymore. <br>i think tcp santa cruz was the first to propose it.<br><br>does someone know experimental results of using a modified TCP based on this idea? <br><br>-saverio<br><br><div class="gmail_quote">On Fri, Feb 20, 2009 at 6:29 PM, RAMAKRISHNAN, KADANGODE K (K. K.) <span dir="ltr"><<a href="mailto:kkrama@research.att.com">kkrama@research.att.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Injong's note prompted me to write this quick note:<br> We have worked on LT-TCP, an enhancement to TCP to deal with lossy end-end paths (the topic of discussion here, I guess).<br> LT-TCP uses ECN as an "unambiguous" indication of congestion, and treats loss as being primarily non-congestion related loss. Of course, this is not always true, even if the end-end path adopted ECN (because of the path operating at a load that is beyond the dynamic range of the ECN based feedback congestion avoidance). In addition, ECN itself may not be enabled on all the hops in the end-end path (even if we enable the use of ECN in the network). Therefore, to allow for backwards compatibility, we had proposed using the correlation between loss with observed end-end delay in the absence of ECN indications to cause the end-systems to fall back out of LT-TCP and use TCP's loss-based congestion response. We had talked about this at discussions we have had in the ICCRG meetings (2006 etc). We think for such a coarse use of delay as a guide to determine if the losses we are encountering are unrelated to congestion or if they are due to both congestion and other sources of loss i!<br> s possible. Whether we can do better than that of course, is a separate question...<br> Thanks,<br> <font color="#888888">--<br> K. K. Ramakrishnan Email: <a href="mailto:kkrama@research.att.com">kkrama@research.att.com</a><br> AT&T Labs-Research, Rm. A161 Tel: (973)360-8764<br> 180 Park Ave, Florham Park, NJ 07932 Fax: (973) 360-8871<br> URL: <a href="http://www.research.att.com/info/kkrama" target="_blank">http://www.research.att.com/info/kkrama</a><br> </font><div class="Ih2E3d"><br> <br> -----Original Message-----<br> From: <a href="mailto:end2end-interest-bounces@postel.org">end2end-interest-bounces@postel.org</a> [mailto:<a href="mailto:end2end-interest-bounces@postel.org">end2end-interest-bounces@postel.org</a>] On Behalf Of Injong Rhee<br> Sent: Thursday, February 19, 2009 10:08 PM<br> To: Fred Baker; David P. Reed<br> Cc: end2end-interest list<br> Subject: Re: [e2e] TCP Loss Differentiation<br> <br> </div><div><div></div><div class="Wj3C7c">Perhaps I might add on this thread. Yes. I agree that it is not so clear<br> that we have a model for non-congestion related losses. The motivation for<br> this differentiation is, I guess, to disregard non-congestion related losses<br> for TCP window control. So the motivation is valid. But maybe we should look<br> at the problem from a different perspective. Instead of trying to detect<br> non-congestion losses, why not try to detect congestion losses?<br> Well..congestion signals are definitely easy to detect because losses are<br> typically associated with some patterns of delays. So the scheme would be<br> "reduce the congestion window ONLY when it is certain with high probability<br> that losses are from congestion". This scheme would be different from<br> "reduce whenever any indication of congestion occurs". Well my view could be<br> too dangerous. But given that there are protocols out there, e.g., DCCP,<br> that react to congestion much more slowly than TCP, this type of protocols<br> may not be so bad...<br> <br> <br> <br> <br> </div></div></blockquote></div><br><br clear="all"><br>-- <br>Prof. Saverio Mascolo<br>Dipartimento di Elettrotecnica ed Elettronica<br>Politecnico di Bari<br>Via Orabona 4<br>70125 Bari <br>Italy<br>Tel. +39 080 5963621<br> Fax. +39 080 5963410<br><a href="mailto:email%3Amascolo@poliba.it">email:mascolo@poliba.it</a><br> <br><a href="http://c3lab.poliba.it">http://c3lab.poliba.it</a><br><br><br>=================================<br> This message may contain confidential and/or legally privileged information.<br> If you are not the intended recipient of the message, please destroy it.<br> Any unauthorized dissemination, distribution, or copying of the material in<br> this message, and any attachments to the message, is strictly forbidden.<br> </blockquote></div><br></div></body></html>