[e2e] TCP Loss Differentiation

[Fred Baker]

The problem is that "elevated RTT" doesn't necessarily mean a lot.  
Consider ftp://ftpeng.cisco.com/fred/RTT/index.html.

ftp://ftpeng.cisco.com/fred/RTT/Pages/2.html 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.

ftp://ftpeng.cisco.com/fred/RTT/Pages/3.html and ftp://ftpeng.cisco.com/fred/RTT/Pages/6.html 
  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.

On Feb 20, 2009, at 10:53 AM, Saverio Mascolo wrote:

> 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.
> i think tcp santa cruz was the first to propose it.
>
> does someone know experimental results of using a modified  TCP  
> based on this idea?
>
> -saverio
>
> On Fri, Feb 20, 2009 at 6:29 PM, RAMAKRISHNAN, KADANGODE K (K. K.) <kkrama at research.att.com 
> > wrote:
> Injong's note prompted me to write this quick note:
> We have worked on LT-TCP, an enhancement to TCP to deal with lossy  
> end-end paths (the topic of discussion here, I guess).
> 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!
>  s possible. Whether we can do better than that of course, is a  
> separate question...
> Thanks,
> --
> K. K. Ramakrishnan                  Email: kkrama at research.att.com
> AT&T Labs-Research, Rm. A161        Tel: (973)360-8764
> 180 Park Ave, Florham Park, NJ 07932    Fax: (973) 360-8871
>       URL: http://www.research.att.com/info/kkrama
>
>
> -----Original Message-----
> From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org 
> ] On Behalf Of Injong Rhee
> Sent: Thursday, February 19, 2009 10:08 PM
> To: Fred Baker; David P. Reed
> Cc: end2end-interest list
> Subject: Re: [e2e] TCP Loss Differentiation
>
> Perhaps I might add on this thread. Yes. I agree that it is not so  
> clear
> that we have a model for non-congestion related losses. The  
> motivation for
> this differentiation is, I guess, to disregard non-congestion  
> related losses
> for TCP window control. So the motivation is valid. But maybe we  
> should look
> at the problem from a different perspective. Instead of trying to  
> detect
> non-congestion losses, why not try to detect congestion losses?
> Well..congestion signals are definitely easy to detect because  
> losses are
> typically associated with some patterns of delays. So the scheme  
> would be
> "reduce the congestion window ONLY when it is certain with high  
> probability
> that losses are from congestion". This scheme would be different from
> "reduce whenever any indication of congestion occurs". Well my view  
> could be
> too dangerous. But given that there are protocols out there, e.g.,  
> DCCP,
> that react to congestion much more slowly than TCP, this type of  
> protocols
> may not be so bad...
>
>
>
>
>
>
>
> -- 
> Prof. Saverio Mascolo
> Dipartimento di Elettrotecnica ed Elettronica
> Politecnico di Bari
> Via Orabona 4
> 70125 Bari
> Italy
> Tel. +39 080 5963621
> Fax. +39 080 5963410
> email:mascolo at poliba.it
>
> http://c3lab.poliba.it
>
>
> =================================
> This message may contain confidential and/or legally privileged  
> information.
>  If you are not the intended recipient of the message, please  
> destroy it.
> Any unauthorized dissemination, distribution, or copying of the  
> material in
> this message, and any attachments to the message, is strictly  
> forbidden.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090220/832d5387/attachment-0001.html