[Iccrg] About cautious use of unreliable feedback

[Lachlan Andrew]

Greetings Michael,

Good suggestion.

CTCP sort of does that by reverting to Reno when its estimate of delay
is high.  RTT can't have severe negative-going spikes (because there
is an intrinsic minimum delay), and so the only noise to contend with
is positive-going noise,  which it handles conservatively.

Cheers,
Lachlan

On 03/02/2008, Michael Welzl <Michael.Welzl at uibk.ac.at> wrote:
> Hi all,
>
> This is just a thought that I'd like to share:
>
> There are plenty of proposals for doing better congestion
> control by using more feedback than standard TCP, and they
> generally have this problem that the mechanism can fail
> due to noise (e.g. when such feedback is wrongly interpreted).
>
> So we end up with proposals for TCP variants which are
> shown to be a lot better than standard TCP (or other
> competitors) under certain conditions, but may not be very
> realistic for wide scale deployment, and standard TCP which
> doesn't use such extra feedback at all.
>
> What we seem to be missing are proposals which strike
> a middle ground, i.e. use additional feedback, but in
> a more cautious way.
>
> Let's assume that TCP X uses an RTT increase as an indication
> of a growing queue, and hence it reacts, e.g. by increasing
> the rate more conservatively or even decreasing it.
> TCP X would then react to effects such as link layer ARQ,
> and more severe problems such as route flapping would
> lead to completely wrong behavior.
>
> Now, why doesn't someone propose TCP Y, which is more
> stable against sporadic fluctuations by reacting IFF
> the RTT has not changed by more than a certain percentage
> for a long time (indicating that no route flapping occurred,
> and that there are no interactions on a wireless link),
> and the RTT has begun to gradually increase?
>
> Wouldn't that be a much more realistic thing to do?
>
> Sure, TCP Y would react to route flapping or link
> layer ARQ as it occurs for the first time, but that
> might be just the right thing to do - the idea would
> be to stop using this kind of feedback until it
> stabilizes again.
>
> I took queing delay as an example because this is
> quite a common type of feedback to use, but the point
> that I'm trying to make applies to all kinds of
> additional feedback (e.g., trying to get a
> bandwidth estimate with packet pairs or trains,
> whatever).
>
> I'd be interested in your thoughts. Wouldn't that
> be a good way to move forward, especially for TCP++
> proposals that should take the ICCRG - TCPM path?
>
> I haven't personally reviewed one of our drafts yet,
> but if I was to review TCP X above, I would vote against
> it unless the authors can show that it works in the
> presence of route flapping or heavy RTT fluctuations
> from link layer ARQ.
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>


-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan