[e2e] TCP un-friendly congestion control

[reddy at ee.tamu.edu]

It seems feasible to separate congestion-related and non-congestion
related losses by simply delaying the congestion response by one RTT.
Noncongestion losses (channel errors, packet reorderings) hopefully
get fixed in one RTT (either through link-level retransmission,
 or packet arriving a little late). If the receiver keeps asking for
that packet after the delay -the sender could assume it is congestion
related and respond accordingly.

The following paper shows that this works well in wireless channel
errors case:

http://dropzone.tamu.edu/techpubs/2003/TAMU-ECE-2003-01.pdf

Our current work is showing similar promise with packet reorderings.

Reddy

On Fri, 6 Jun 2003, J. Noel Chiappa wrote:

>     > From: "dave o'leary" <doleary at juniper.net>
>
>     > For more information:
>     > http://netlab.caltech.edu/FAST/
>     > http://netlab.caltech.edu/pub/papers/fast-030401.pdf
>
> Thanks for the pointers; in looking over the material there, I came across a
> point which I'm wondering about, and I'm hoping someone here can enlighten me.
>
>
> I've always heard that at extremely high speeds packet-loss based congestion
> feedback (Reno) had problems in practise, because since you can't
> differentiate between i) packet losses caused by congestion, and ii) losses
> caused by errors, then if you have a roughly constant BER then as the link
> speed goes up, you start getting a faster rate of 'false' (i.e. error-caused,
> not congestion-caused) loss signals, which cause unneeded (and undesirable)
> reductions in sending speed. I assumed that queueing-delay based congestion
> feedback (Vegas) would avoid this issue.
>
> This point is not made in detail in the papers, although there is a brief
> comment which allude to this whole area - "Reno .. must maintain an
> exceedingly small loss probability in equilibrium that is difficult to
> reliably use for control".
>
> I am informed that this comment also refers to the difficulty of using as a
> control signal something (the congestion loss rate) which is small and
> difficult to estimate reliably; not only that, but as the paper points out,
> the quantization of that signal is large compared to the signal amplitude,
> making for even more trouble.
>
>
> So now I finally get to my question!
>
> I would suspect that in practise, the first aspect I mentioned (two different
> kinds of loss signal getting mixed up) is probably an even bigger problem
> than the other one (the difficulty of using such a small signal for
> feedback).
>
> Does anyone have sany information on this, either from real-life measurements,
> or simulations?
>
> 	Noel
>
>

===========================================================================
A. L. Narasimha Reddy			Phone: 979-845-7598
Texas A & M University			Fax: 979-845-2630
214 Zachry				email: reddy at ee.tamu.edu
College Station, TX 77843-3128		http://ee.tamu.edu/~reddy