Hi Ian, Ian McDonald wrote:
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. 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.
You absolutely CAN switch to a packet based equation (assuming s is fixed at MSS), because that packet based equation will have ENTIRELY IDENTICAL BEHAVIOR to the byte based equation! Specs talk about observed behavior, that is what makes them specs.
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...
This is not quite right. Applications might be able to cause *transient* unfairness (in a purely packet-based implementation) by switching to a larger packet size after sending small packets for a while. The unfairness is only transient because, if the app keeps sending large packets, eventually the loss event rate will catch up with the app's current behavior.
Personally, I do not believe this transient unfairness is a critical issue. Preliminary simulations showed apps didn't gain in the long run from doing this. None of the current discussion has changed my mind. Some real experiments could.
Eddie - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
