[e2e] TCP Loss Differentiation

[RAMAKRISHNAN, KADANGODE K (K. K.)]

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 is 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...