After a long discussion with Gerrit, I would just like to point out
two things that needs to be fixed in TFRC/CCID3:
1) Make it "explicit" to use a consistent "s" throughout the drafts/RFCs.
- The reason why we see this as a problem is because of two things:
* The Initial rate calculation: X_inst = X = W_init/R =
min(4*MSS, max(2*MSS, 4380))/R, and then use t_ipi = s/X_inst. What is
s here? MSS or the actual/average packet size?
* As pointed out in the earlier mails by Eddie, using a large
"s" for X_calc and then using a small "s" for t_ipi.
2)Make it clear on what "s" should be. We personally feel "s" can just
be the average packet size since if the packet size is constant, then
average of "s" is constant and if "s" is varying then averaging seems
to be fine. We are still not able to decipher why we require MSS to be
used as "s". Maybe we are mere mortals :)
After all the arguments/discussions, I would like to add "Let peace be
with you all" :)
Regards
Arjuna
On 10/4/06, Gerrit Renker <gerrit@xxxxxxxxxxxxxx> wrote:
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...
--
Dr.Arjuna Sathiaseelan
Electronics Research Group
University of Aberdeen
Aberdeen AB24 3UE
Web: www.erg.abdn.ac.uk/users/arjuna
Phone : +44-1224-272780
Fax : +44-1224-272497
