[Iccrg] About cautious use of unreliable feedback

[Michael Welzl]

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

This minimum delay is called basertt in the draft. What
happens to it when the connection is rerouted from a
small-RTT path to a higher-RTT path?

The only thing that I could find in the draft about setting
this value is: "When a connection is started, basertt is updated
to be the minimum RTT observed during the 3-way handshake. basertt
is cleared and set to zero if a retransmission timeout is hit.
It is continually measured and updated to track changing network
conditions. "

Does "continually measure" mean that we always look for the
smallest possible value (always calculate the minimum) ?

I assume it does. This alone will not help when the
connection's minimum RTT generally increases because of
a path change.

Properly doing what I said would require the mechanism
to continuously update basertt in an appropriate fashion,
which includes switching to a new, possibly larger value.
This would probably have to be done by detecting that
it turned out to be the minimum, which was hit at
least X times, during the last interval of Y RRTs
(which brings about the difficulty of properly choosing
X and Y, of course).

Cheers,
Michael