I suppose you can find the algorithms in the bibliography at the end of the RFC.
[...]
> I think that it' s really excessive increase the srtt of 4*mdev. Also I
> think that it' s completly broken start with a mdev of 3/4 sec (that then
> icrease of at least 3 sec the first retransmit timeout).
>
> So I think that we should default to 0 mdev at sock creation time and
> caculate the rto as the SRTT + MDEV (not 4*MDEV) changing
>
> tp->rto = (tp->srtt >> 3) + tp->mdev;
> to
> tp->rto = (tp->srtt >> 3) + (tp->mdev >> 2);
>
> I have not done math to prove that this changes would not collapse the
> whole Internet (because I am not able to do that ;-), but sound obvious to
> me that a first retransmit timeout of ~15 times > of the first rtt is
> wrong.
>
> With my changes if the first rtt is of 143 the first rto become 319 (>2
> rtt). This would fit in the RFC793 algorithm and would get the
> improvements of the mdev and congestion avoidance calculations.
>
> I append a simple proggy that done the calc for me (#define STOCK 1 to get
> the 2.1.121 calculation and STOCK 0 to get _my_ calc).
[...]
I don't think that changing the algorithm to use MDEV instead of MDEV*4
is a right thing. I have no figures but I suppose that
SRTT + MDEV keeps the probability of false retransmittions too large.
I can agree with you that initialization of tp->mdev by m<<2 when the previous
measurements are absent is probably an overhead.
If we want to keep the initial rto about 3*m as comments say the initial
value for tp->mdev should be not more than m<<1.
In addition you may try to remove the contribution
of negative RTT differences to the MDEV evaluation as Rogier Wolff
has suggested. It'd be interesting to know how the modification
changes the RTO value and the total TCP performance.
Best wishes
Andrey V.
Savochkin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html