[Iccrg] About cautious use of unreliable feedback

[Lachlan Andrew]

Greetings Michael,

If the baseRTT goes down, it is detected and CTCP keeps working
properly.  If the baseRTT goes up, CTCP becomes like Reno.  That is
why I said it "responds cautiously" to delay, as you suggested.  I
agree that the draft should explain more precisely how baseRTT is set,
but the actual algorithm is much less sensitive to it than Vegas was.
I interpreted "continually measure" as "take the minimum observed RTT
since it was last reset", the way Vegas does.

The only way that I can see that it is non-cautious is if it gets a
time-out when there is persistent congestion on one of the links, in
which case it over-estimates baseRTT.  However, even that is not a
real problem, because CTCP will detect the fluctuations in queue size
as a sign not to go into its "aggressive" mode.

Resetting baseRTT the way you propose makes CTCP more aggressive, but
has the possibility of making it too aggressive.  What it actually
does makes it never less aggressive than Reno, and only more
aggressive when it has very good evidence that it is safe to be.


While we're turning this into a discussion of CTCP, I think the Vista
implementation shows that it is counter-productive to be too worried
about having specifications that are very Reno-friendly and always
have benefits over Reno.  The current Vista implementation behaves so
extremely differently from the specification in the internet draft
that the details we have been discussing in assessing the draft fall
into the shadows.  (That statement is based on Doug's measurements of
Vista and my measurements of the Linux version of CTCP, which we can
see implements the spec.)

Similarly with BIC, there was a time when its Linux implementation was
*way* too aggressive due to a bug, rather than the spec itself.
Perhaps we should focus on making the algorithms and descriptions as
simple/specific and bug-tolerant as possible, rather than worrying
about whether they retain their benefit over Reno when the delay is
estimated incorrectly.

$0.02,
Lachlan

On 03/02/2008, Michael Welzl <Michael.Welzl at uibk.ac.at> wrote:
> > 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
>
>


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