Yes, this could be explained clearer - and probably should be.
My thinking was:
* The TCP RTO was 3 RTTs+variance term.
* TFRC does not usually provide prompt feedback of status from
a receiver. It could be up to one RTT later before a sender
receives feedback.
Hence, NFT is (3RTT)+RTT.
- If people know more, do tell.... and correct me.
Best wishes,
Gorry
Michael Welzl wrote:
Hi all,
I'm confused by the idea of setting RTO=4*RTT in TFRC.
From RFC 3448:
--
We further simplify this by setting t_RTO = 4*R. A more accurate
calculation of t_RTO is possible, but experiments with the current
setting have resulted in reasonable fairness with existing TCP
implementations [9].
--
(where [9] is Joerg Widmer's master thesis).
I'd like to understand where the number 4 comes from. Was that
just a magic number that worked well in Joerg's tests?
If we apply the same intuition (whatever it was) that led to
the choice of RTT/2 as an initial value for RTTVAR in RFC 2988
and forget about the EWMA processes for a minute, it would seem
reasonable to set RTO to RTT + 4 * RTT/2 = 3*RTT instead...
Also, I wonder how people apply the equation in other settings -
is it a common thing to set RTO to 4*RTT when using it, or
is this specific to TFRC?
Cheers,
Michael
--
PS: maybe off-topic because it's related to RMT and not DCCP,
but it's still somewhat related and maybe you could also
answer that one in the same message: I noticed that,
in RFC 4654, the following changes were made to the equation:
1) s became 8 s
2) b became 1
3) RTO became 4 (not 4 RTT!)
I can understand 1) above, as this means that a non-DelACK
receiver is assumed. I can also understand 2), because you need
the throughput per 8 seconds (not 1 second) for the protocol -
but I can't understand the reasoning behind replacing RTO with 4.
I must be missing something, but this is really confusing me - I
would greatly appreciate an explanation. Thanks!!
