Reply Letter to
Subject: COMNET: Minor revision of your paper requested.
Date: 3 Sep 2012 23:44:26 +0100
Ref.: Ms. No. COMNET-D-12-26R1
Robust and Fair Multicast Congestion Control (M2C)
Thanks for these suggestions for improving our paper.
Please find below (in blue) our answers to some questions
Reviewer #1: The authors addressed satisfactorily the comments of the first revision.
However, some minor
changes have to be made before publishing the paper which should not require another
round of
revision:
- Page 15 you claim: "The fairness varies but only from one extreme level to
another: totally fair (F ? 1) or totally unfair (F ? 0.5)".
However, the reader cannot infer this by reading the data contained in Table 4. Maybe
a cumulative distribution function would be more expressive than a table.
We replaced Table 4 by figure 20: this is a cumulative distribution of fairness (% of
experiments having a fairness < x ). It can be seen especially in the local platform case,
webrc against webrc, that the fairness is either very bad (around 0.65 ) or good .
- Figure 19 (a) and (b) are unreadable. Please make Figure (a) and Figure (b) span the
two columns.
done
- Page 16 the last phrase of Sec. 8 : "The same applies" instead of "The same apply"
done
- Section 8.1.4. Dynamics of rate convergence: are the dynamics shown in Figure 17
really representative
of WEBRC and M2C? Is the pathological WEBRC behaviour shown in Fig. 17 (a)
representative or it is only
seldom observed? Please clarify in the revised manuscript.
Figure 17 illustrates one case, where 3 distinct phenomena may be observed :
convergence delay (this is studied in detail in section 9), global fairness (this is the topic
of section 8), but also rate variation (could be seen as fairness at a smaller time scale).
Section 8.1.4 is intended to illustrate this. In addition to the example of Figure 17, we
show the CDF of rate variation (new figure 18). Although the global shape depends on
the experiment parameters, it can be seen that the standard deviation (in % of link rate)
of WEBRC rate is quite high in many cases and above the standard deviation for M2C
rate.
- Overall comment on the figures: please make sure the figures are well readable (Figure
18 is difficult to
read, Figure 16 axis labels are very hard to read, Figure 15 text is too small, ... )
We tried to improve readability
Reviewer #2: This paper has been previously reviewed, therefore we shall not repeat.
Most of our --2 cosulting reviewers have done this work-- objections and suggestions
have been properly addressed in the current revision. Thank you!
An issue that has escaped us during the prior review and could be improved is Sect.
4.2.3: Please kindly clarify why and how the Beta(IPT) must be computed *per packet*,
and not per ERTT cycle. The intuition of the source injection rate decreasing per packet
with Beta, hence compensated in Fig. 7 by a 'symmetrical 1/Beta' SS increase per pkt
was insufficient for our understanding. Reading the original PhD thesis and the
associated code didn't clarify either.
We clarified the text.:
For both TCP and M2C, during slow start, the rate increases exponentially in function of
time. For TCP the rate (theoretically) doubles each RTT while for M2C it is
(theoretically) multiplied by (P**K ) -1 each TSD. In practice the rate is increased more
smoothly, at the packet granularity, this has the advantage that there is no need to use a
timer to decide when to increase the rate. For TCP the window is increased by one
packet for each received Ack, while for M2C it is increased by a factor (IPT)-1 for each
received packet. Note that indeed  (IPT1)-1 *  (IPT2)-1 =  (IPT1+IPT2)-1 so after
TSD, the rate has been increase by a factor  (TSD). This has the advantage that the
increase is not dependant on our estimation of RTT.
Editorials
Section 1
- "Deering's thesis" + citation
done
- "When congestion occurs, this mechanism reduces its impact." - I would remove this
phrase completely, since you seem to contradict the previous sentence.
done
- "on the Internet" - capitalize Internet
done
- " First, multicast is basically one way designed, because for obvious scalability reasons,
it is not possible for a multicast source to gather feed-back information from all its
receivers"
First, multicast congestion control must operate one-way since in not possible for a
multicast source to gather feed-back information from all its receivers, for scalability
reasons.
done
Section 2
- "very high scalability" - use of "very", "a lot", "many" etc. it's not recommended in
scientific papers, since it's ambiguous, either you remove "very" or you add a
comparison eg. "... more scalable than previous proposals "
removed
- "These protocols and more specifically WEBRC and M2C, as they are the latest
multicast congestion control protocols," - These state of the art multicast congestion
control protocols together with our proposed M2C protocol were tested ... `
replaced
Section 3
L37, c2: source-driven (dash required)
done
Section 10.3
- " during the malfunctioning." – remove
removed