[e2e] TCP Loss Differentiation
RAMAKRISHNAN, KADANGODE K (K. K.)
kkrama at research.att.com
Fri Feb 20 09:29:29 PST 2009
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...
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
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...
More information about the end2end-interest