[Iccrg] About cautious use of unreliable feedback

[Michael Welzl]

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