[Iccrg] About cautious use of unreliable feedback

[Michael Welzl]

> Thanks for sharing these thoughts. Imho, I don't see a problem on
> estimating path characteristics such as path delay and queueing delay
> by measuring RTT. First, this has been used for some time to trigger
> RTT timeout, as an example. Second, there are good aging mechanisms in
> place (exponential averages).

Well, that's a different thing - the RTO will adapt
when the minimum RTT increases, whereas the CTCP
baseRTT doesn't (to my understanding). Indeed EWMA
is a reasonable way of applying aging, so that would
fit here.

Anyway, I accept Lachlan's point about CTCP, where he
says that it's reacting like Reno when the baseRTT
goes up; this is may not be the ideal behavior, but
it's conservative enough then.


> But, the example you are bringing up (>> which includes switching to a
> new, possibly larger value) could be difficult to define with 100%
> certainty (perhaps, the right way is to signal that back using ECN). A

100% certainty will never exist  :)
But reasonable approaches can - as you said, aging mechanisms
like EWMA appear to do the trick (at least it seems that they
are good enough for RTO estimation).


> larger value of RTT for X duration, could just mean a steady
> cross-traffic passing the shared link and not a route change, isn't
> it? So, how to differentiate the two with 100%? In any case, most of
> the delay-based protocols are conservative to large RTT.

Cross traffic wouldn't give you a value which doesn't
fluctuate by more than Y% for the duration of X, which
is what I said. That's a better indicator.


> Another point is that route changes should result in packet loss while
> there is no convergence, since, packets are on the way to the router,
> and that would consistently trigger a retransmission timeout, cleaning
> up the baseRTT. Finally, one can argue that, the router changes happen
> on another time granularity larger than the lifetime of a typical
> (HTTP) TCP connection.

Agreed. I'm not sure if we can assume that route changes
will always result in packet loss - more complex things
than just a failure with ensuing IGP or EGP reconvergence
can happen inside a network, some of which could cause
the RTT to go up.

I don't know how often such "consistent RTT increase
without a lot of loss" things happen in practice,
though. Indeed, clearing baseRTT upon a timeout
is quite a sound thing to do.

Lachlan is right, this has turned into a CTCP
discussion. Well, it seems to me that CTCP fits
my criteria for being "cautious enough".

Cheers,
Michael