Hi Ian, what you prove is right, you there is no contradiction, just confusion due to the numerical example, cf. inline. Quoting Ian McDonald: | > I disagree with this reading of the RFC. The RFC explicitly allows the sender | > to calculate X as if every packet had size 's = MSS'. As usual, the | > implementation can then implement any simplifications such an assumption would | > allow. An implementation that assumes 's = MSS' can therefore calculate a | > sending rate in packets per second. | > | > Eddie | > | OK. Time for some maths with the TCP throughput equation. I am using | an online version here backed up with testing with my modified DCCP | stack - this matches on runs to within 10% of this equation. The | online equation is here - http://wand.net.nz/~perry/max_download.php - | in the examples below I have changed rtt to 250 ms and loss to 5 %. | | In this online calculator the value for s is put into MSS. The reason | for this is we are assuming we are sending maximum size packets which | may not be applicable for DCCP but is for TCP. So we vary the MSS to | reflect s here. | | Now starting with a s of 1460 bytes we get a throughput (Xcalc) of | 15221 bytes/sec. Now t_ipi is s/X_inst and X_inst on average is X_calc | (it is just adjusted to prevent oscillation). So t_ipi is 96 msecs. | | Now change s to 300 bytes we get a Xcalc of 3128 and a t_ipi of 96 | msecs. Put in ANY number for s and you will get the same t_ipi of 96 | msecs. No numerical example is needed, this follows from: 1) X_calc = s * f(rtt, b, p) [RFC 4342, 3.1] 2) by [RFC 4342, 4.3], X_inst = X_calc whenever R is constant (and then R_sqmean = R) 3) t_ipi = s/X_inst = s/X_calc = s/(s * f(rtt, b, p) = 1/f(rtt, b, p) ==> Hence t_ipi is independent of `s' when RTT is constant. If RTT is not constant, then X_inst = k * X_calc (where k = R_sqmean / sqrt(R_sample) is a real number); therefore t_ipi = s/X_inst = 1/k * s/X_calc = 1/k * 1/f(rtt, b, p) ==> Hence t_ipi is again independent of `s'. You have therefore shown a point made the last email: If `s' is clamped to a fixed value such as the MSS, but is allowed to change over time (in the extreme case s is very small compared to MSS), then an update to the loss interval estimation procedure is needed. This will change p in the above equation, with that X_calc and t_ipi. The throughput equation is ignorant of this issue, the point is in how the input `p' to the equation is sampled. | This illustrates my point that CCID3 is a packet per second based | congestion control. | | Now if we specify the s is 300 to the implementation we get the | desired result, if we average it we get the correct result. However we | can't switch to a packet based equation because if we do the spec says | we should use s=MSS. Lets assume MSS=1460. Now Xcalc is 15221 | bytes/sec. t_ipi is 96 msecs. And we can send the correct rate of | packets. | | OK Now working through the example shows that my logic was wrong. I | guess thats what defence of ideas is about - proving it and my idea | was wrong. I apologise for wasting everybody's time! | | However this does show an application can't cheat by specifying the | wrong packet size which the spec worries about. Maybe my working | through this helps resolve this a little...
