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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
