Reviewer(s)' Comments to Author:
Reviewer: 1
Comments to the Author
This paper addresses the well-known "mice and elephants" problem. It points out an imminent and serious implication of the problem that interactive TCP applications generate "dummy" packets which jeopardize the "statistical multiplexing" of TCP networks. This is a significant contribution because until now, people believe that the bandwidth requirements should be much less than the aggregate maximum rates of all the TCP flows assuming that those flows cannot arrive at their maximum rates at the same time.
This paper also models the response times of the TCP flows including application-limited flows and fully backlogged flows. Based on the simulation results, it shows that interactive clients always have an incentive to send at a TCP-fair rate, because the corresponding response time performance always outperforms the pure interactive approach. Moreover, it reveals that due to random packet losses, the gain is much larger for RED routers. This is the second contribution of the paper.
Since the problem caused by the interactive TCP applications is difficult to solve because the TCP friendly misbehavior is hard to detect, the paper proposes several countermeasures which can be used by short-lived TCP flows. These solutions are simple, easy-to-deploy, and sustainable so that they are capable of effectively demotivating clients from applying the greedy TCP-fair approach. In particular, it is shown that a diversity method, accompanied with RED routers in the network, performs remarkably well. Still, the short-term padding approach appears even more attractive. However, it could be implemented at the application layer, without requiring any TCP-level modifications.
Before the paper is published, I propose the following modifications.
---
Firstly, I think some terms in this paper are confusing. For example, to my understanding, "padding approach", "greedy TCP-fair approach" and "sending "dummy" packets" in fact mean the same strategy used by the interactive TCP applications. When I read the paper I was lost at first because I didn't know what is the relationship among the three.
-----
(*) In the revised version of the paper, we stick with only one term, "fully-backlogged approach," to avoid any confusion. We made the following modifications in the paper:
Page 2:
"First, by adopting fully-backlogged approach, clients avoid loosing memory in moments of data starvation [8]."
Page 3:
"Here, we quantify the gain a misbehaving client is able to achieve by applying the fully-backlogged approach."
Page 3:
"By establishing this result, we become capable of understanding gains that a misbehaving client can achieve by applying the fully-backlogged approach."
-----
---
Secondly, I think the scenarios of the simulations are not very clear. For example, readers cannot know the number of TCP flows in the simulation whose results are in Figure 5.
-----
(*) We added the following text in section III-D in the revised version of the manuscript, which clarifies the simulation scenario.
"We control the packet loss ratio by varying the intensity of the cross-traffic. The background traffic is composed of http, ftp, and low-rate udp traffic. In addition, we generate a pure interactive flow and an interactive flow converted to a fully-backlogged flow. For each of the flows, we log the experienced packet loss ratio and response-time. Then, we run the experiment multiple times and aggregate the results to calculate the gain ratio. Unless otherwise indicated (e.g., Figure 8), this is the default simulation scenario."
-----
---
All results in the paper MUST BE REPRODUCIBLE!
-----
(*) The results from the paper are reproducible. We publish the corresponding ns-2 code and tcl scripts used for running the simulations at the following link.
http://networks.cs.northwestern.edu/Intcp/code/
We add the following text in section III-D.
"The modified ns-2 code and simulation scripts are available at http://networks.cs.northwestern.edu/Intcp/code/"
-----
Reviewer: 2
Comments to the Author
This paper investigates the issue where interactive tcp flows (like telnet, gaming and web) send dummy packets to the Internet to improve their response time performance. The authors state that doing this will significantly jeopardize the Internet's statistical multiplexing principle and propose three approaches.
After reading this paper I have the following questions:
1) The problem is overly exacerbated. The interactive tcp flows only accounts for a small percentage of the Internet traffic;
-----
(*) The reviewer correctly observes that the percent of interactive traffic in Bytes is rather small. However, the percent of interactive flows is not negligible. For example, according to [10], network games, which are becoming increasingly popular, alone constitute a significant fraction. According to a more recent measurement [11], this percent has decreased due to penetration of peer-to-peer flows, but it is still far from negligible.
Most importantly, interactive flows (e.g., chat and gaming) are long-lived in general. If all these interactive flows are converted to fully-backlogged flows, then a substantial amount of bandwidth will be wasted carrying the "dummy" packets which will significantly impact the overall performance of the Internet.
Modification in the paper (Section I):
"While interactive flows account for a small fraction of the total Internet traffic in bytes, their percent in terms of the number of flows in the Internet is much higher [10],11]. Moreover, interactive flows (e.g., chat and gaming) are long-lived in general. Consequently, a large-scale deployment of this approach
"
[10] S. McCreary and K. Claffy, "Trends in wide area IP traffic patterns -A view from ames Internet exchange," Proceedings of the 13th ITC Specialist Seminar on Internet Traffic Measurement and Modeling, 2000.
[11] T. Karagiannis, K. Papagiannaki, and M. Faloutsos, "BLINC: multilevel traffic classification in the dark," in Proceedings of ACM SIGCOMM '05, Philadelphia, PA, Aug. 2005.
-----
2) Plus, the end users will not use fully-backlogged approach to improve the response time. The reason is that if they all do this, they will all lose, as shown in Figure 8. Therefore, the worry for the fully-backlogged tcp for interactive applications is false;
-----
(*) There are two issues here. First, we agree with the reviewer that the overall performance degrades and all lose if everybody uses fully-backlogged approach, as shown by Figure 8. Second, we disagree with the reviewer that the worry for the fully-backlogged tcp for interactive applications is false. Before replying more directly to the specific fully-backlogged tcp example, we feel free to provide a somewhat related illustrative example from today's world. The fact is that wars between countries are a very bad thing, simply because all lose: soldiers on both sides die. If we follow the reviewer's argument, then we can conclude that the worry about wars in the world is false. Unfortunately, this is not the case. Indeed, because one country cannot control actions of other countries (i.e., other countries may use their armed forces), each and every country in the world has its own armed forces.
Going back to the original problem, the hard fact is that users are selfish. The interaction among the users in the Internet is like interaction among players in a non-cooperative game. In a non-cooperative game players can cooperate, but any cooperation must be self-enforcing. Unlike cooperative games, no third party can enforce the contract. In the Internet, as long as users remain TCP-friendly, any policing mechanism deployed in the network won't even detect any violation of the rule of the game. Given the fact that a user can always improve its response time performance by applying the fully-backlogged approach, a greedy user will always be tempted to adopt this approach and increase his/her pay-off.
This in addressed in section I as well as II-B. Following is the excerpt from the paper:
"While the absolute performance of all flows would necessarily degrade in such a case, a troubling observation is that those applying the fully-backlogged approach would still benefit relative to the regular clients. Hence, the dangerous incentive remains."
-----
3) The gain ratio is not a good measure of response time performance improvement; it over-estimates the performance improvement when the response time is small. For interactive applications, as long as the response time is within a small range (say less than 50ms~100ms), any further deduction is meaningless to the users. Given this, for example, in Figure 3, only the part when the loss rate is higher than 5% (i.e., the non-backlogged response time is large) is worthwhile to improve. However, for such high-loss rate, the proposed model is very inaccurate. As shown in Figure 5, the simulation gain is far below the theoretic prediction, which means the problem is not as severe as the model indicates;
-----
(*) There are two issues here. First, the range of response times for interactive applications and their satisfaction is still an open research topic. The recent results indicate that there is tremendous variation in user satisfaction, in interactive applications, for the same resource share [9].
Second, there are scenarios, such as multiplayer games over the Internet, where users would still care about improving their relative performance. A player with lower response-time in a multiplayer shooting game is more powerful than its opponent.
Modification in the paper (Section-I):
"There are two reasons why users would want to reduce the response times. First, while the common wisdom is that 50?100ms is the lower bound that clients care about; this is still an open research question. Recent results indicate that there is a tremendous variation in user satisfaction in interactive applications [9]. Second, there are scenarios, such as multiplayer games over the Internet, where users would care about improving their performance relative to other players, hence reducing their response time."
[9] P. Dinda, G. Memik, R. Dick, B. Lin, A. Mallik, A. Gupta, S. Rossoff, The User In Experimental Computer Systems Research, Proceedings of the Workshop on Experimental Computer Science (ExpCS 2007), June, 2007.
-----
4) The proposed solutions are useful. But, they are also so straight-forward that it is hard to be convinced these are major contributions;
-----
(*) There are two issues here. First, we agree with the reviewer that the solutions presented in the paper are intuitive. However, as shown in the paper, not all intuitive solutions are effective and cannot mitigate the problem. For example, TCP smart framing, which splits data into smaller size segments in a hope that there will be enough segments in the network to trigger fast retransmit in case of packet losses, exaggerates the problem instead of improving the response time. We present the results and give insights about why TCP smart framing fails to improve response time for interactive applications in section IV-E. Furthermore, we show that differentiated minRTO approach, another intuitive approach, is not very effective compared to short-term padding and diversity approaches. The bottom line is that each potential solution, intuitive or not, must be carefully evaluated to understand all possible consequences.
Second, the solutions alone are not the only contributions of this paper. The key contribution, in our opinion, is the formulation and analysis of a new and relevant networking problem that has the potential to severely degrade the overall performance of the Internet.
-----
5) Another minor point for presentation. There are so many emphasized words, which lead to no emphasis and read quite annoying.
-----
(*) We have changed most of the emphasized words back to normal font in the revised version of the manuscript. We left few of those where we strongly feel readers should take a note.
-----
Reviewer: 3
Comments to the Author
General Comments
----------------
The paper is well-written, clear, and well argued.
Specific Comments
-----------------
P1
--
P2
--
P3
--
Interactive applications are characterized by two parameters: the data burst size, and the inter-burst arrival time.
-->
[This is a simplification. The author proposes a model but provides little justification, and in fact the model is not really described unambiguously. The proposed model is clarified in subsequent sentences, but starting with a statement which is not really defensible is not justified by the subsequent explanation.]
-----
(*) We agree with the reviewer's point. We change the corresponding text in Section III-A as follows:
"Interactive applications transmit data in cycles. The traffic generated by these applications can be characterized by two parameters: the data burst size, and the inter-burst time. Similar approach has been used to model telnet and gaming traffic [24], [25]."
[24] J. Farber, "Network game traffic modeling," in Proceedings of NetGames'02, Braunschweig, Germany, Apr. 2002.
[25] P. Danzig and S. Jamin, "tcplib: A library of internetwork traffic characteristics," USC Technical Report, Computer Science Department, 1991, Report CS-SYS-91-01.
-----
Denote by p the packet loss probability. Let Ph(i) be the probability that a packet experiences exactly i failure transmission attempts, followed by one successful try. Then, P_h(i) = pi(1 - p).
-->
[What is the justification for this statement? It appears that the author assumes independent loss probabilities, for each subsequent packet. No justification of this assumption is provided and the assumption is not even explicitly stated.]
-----
(*) We assume independent packet loss from an application's point of view. In addition to significantly simplifying modeling, this is a justifiable assumption with RED queues at the network routers, particularly when the application contributes only a tiny fraction of the total traffic into the network. In general, interactive applications generate traffic at very low rate. Even with Droptail queues, due to aggregation effects, the independent assumption holds true. Throughout the paper, we evaluate this assumption by comparing our modeling results with simulations (in both RED and Droptail scenarios).
We add the following text in the revised version of the manuscript.
Modification in the paper (Section III-A):
"We assume independent packet losses [16], [18]."
[16] N. Cardwell, S. Savage, and T. Anderson, "Modeling TCP latency," in Proceedings of IEEE INFOCOM '00, Tel Aviv, Israel, Mar. 2000.
[18] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP Reno performance: A simple model and its empirical validation," IEEE/ACM Transactions on Networking, vol. 8, no. 2, pp. 133-145, Apr. 2000.
-----
-----
Then, according to [15], E[w] becomes
-->
P4
--
However, due to varying queuing delay in simulations, and because the effective RTT increases with the packet loss ratio, we are unable to directly compare the modeling and simulation results in this scenario.
-->
[This comment highlights a defect of the model, namely the assumption of fixed RTT. However, this defect is apparently not catastrophic, or the author would not have presented the model. Hence the reader needs to be shown the discrepancy between the model and the simulations.]
-----
(*) We update Figure 5(a) to compare simulation results and the model output.
Modification in the paper (Section III-D):
"The figure shows deviation in the model output from simulation results. This is due to varying queuing delay in simulations, and because the effective RTT increases with the packet loss ratio (congestion in the network), which is not captured in the model.
However, in order to perform a comparison, we proceed as follows."
-----
P5
--
The above experiments indicate that there exists a "sweet spot," e.g., a packet loss rate for which the misbehaving clients can maximize their performance gain.
-->
The above experiments indicate that there exists a "sweet spot," i.e., a packet loss rate for which the misbehaving clients can maximize their performance gain.
-----
(*) We have fixed this in the revised manuscript.
-----
[This comment is not adequately justified because clients have no reason to maximize "gain". Their natural goal is to minimize their net response time, which might not occur at the same situation where gain is minimized.]
-----
(*) A similar concern has been raised by reviewer-II above. We agree with the point raised by the reviewer that in majority of scenarios users do not have incentive to maximize the gain, but rather they only care about minimizing their net response time. However, there are scenarios where a user would still care about improving its response time performance relative to others. One example is multiplayer games over the Internet. A player with lower response time in a multiplayer shooting game becomes more powerful than its opponent.
We add the following text in section III-E in the revised version of the manuscript.
Modification in the paper (Section III-E):
"Although for most interactive applications users have no incentive to maximize gain, there are scenarios, e.g., multiplayer games over the Internet, where a user would care about improving its response time performance relative to others."
-----
----
network performance to any perceptible amount.
-->
network performance by a perceptible amount.
-----
(*) We have fixed this in the revised manuscript.
-----
----
P6
--
Of course, given the current congestion window permits the TCP sender to transmit more than one packet.
-->
[This is not a sentence]
Of course, this only applies under the assumption that the current congestion window permits the TCP sender to transmit more than one packet.
-----
(*) We have fixed this in the revised manuscript.
-----
P7
--
P8
--
P9
--
On the contrary, due to correlated packet losses, the latency slope is much steeper in the FIFO case.
-->
By contrast, due to correlated packet losses, the latency slope is much steeper in the FIFO case.
-----
(*) We have fixed this in the revised manuscript.
-----
P10
---
This is due to the reason explained
-->
This is for the same reason explained
-----
(*) We have fixed this in the revised manuscript.
-----
to some extend.
-->
to some extent.
-----
(*) We have fixed this in the revised manuscript.
-----
would increases the fast retransmit opportunities by
-->
would increase the fast retransmit opportunities by
-----
(*) We have updated this in the revised manuscript.
-----
duplicate acknowledgements. Of course, provided that the
-->
duplicate acknowledgements, provided, of course, that the
-----
(*) We have fixed this in the revised manuscript.
-----
P11
---
This paper revisited the well-known problem of unfairness between short- and long-lived TCP flows.
-->
[This is a bit misleading, esp given the discussion immediately preceding. The contributions of this paper are particularly relevant to a flow type described in this paper as "interactive", by which is meant, it seems a sequence of short bursts separated by somewhat long pauses.]
-----
(*) We modify the sentence in the revised manuscript:
Modification in the paper (Section VI):
"This paper points out the response time degradations suffered by interactive flows relative to fully-backlogged flows during periods of congestion; it demonstrates that interactive flows can improve their response times by converting themselves into fully-backlogged flows."
-----
===================================================================
Reviewer(s)' Comments to Author:
Reviewer: 1
Comments to the Author
General Comments
----------------
The paper is well-written, clear, and well argued. Below are some minor comments which should improve the paper.
Specific Comments
-----------------
P1
flows, have incentive to improve their performance
-->
flows, have an incentive to improve their performance
-----
(*) We have updated this in the revised manuscript.
-----
everybody would start taking their own
-->
everyone started taking their own
-----
(*) We have updated this in the revised manuscript.
-----
P2
Surprisingly, our modeling and simulation results indicate that not
a single approach is superior, and that the queuing discipline
(e.g., RED vs. Drop Tail) again dominantly impacts the system
performance.
-->
Surprisingly, our modeling and simulation results indicate that
neither approach is uniformly better, and in particular the impact
of each strategy on system performance depends upon the queuing
discipline (e.g., RED vs. Drop Tail) that is in use.
-----
(*) We have updated this in the revised manuscript.
-----
P4
Figure 1 needs improvement. Part of the diagram appears to have been
truncated. The font size in the diagram is too large.
-----
(*) We reduce the font size in the revised manuscript.
-----
Similar approach has been used to model telnet and gaming traffic
[24], [25].
-->
A similar approach has been used to model telnet and gaming traffic
in [24] and [25].
-----
(*) We have updated this in the revised manuscript.
-----
P7
Figure 5b should be labeled as having "artificial losses" so that
it is clear how it differs from Figure 5a.
-----
(*) We label Figure 5b with "artificial losses", and Figure 5a with "congestion-related losses."
-----
P9
Byte --> byte
-----
(*) We have updated this in the revised manuscript.
-----
why converting to --> why convert to
-----
(*) We have updated this in the revised manuscript.
-----
approach-II -->
-----
(*) We have updated this in the revised manuscript.
-----
[Always use capital letters for these names (because they are
names), hence: Approach II. Also, leave out the hyphens.]
On the other extreme, --> At the other extreme,
-----
(*) We have updated this in the revised manuscript.
-----
[The authors use the term "FIFO" to describe queues where RED is not
used. I think it would be better to call these "DropTail" queues,
since the order of service is not actually relevant to the issue
under consideration.]
----
(*) We change "FIFO" in the text to "DropTail" in the revised manuscript.
----
P11
Unfortunately, ECN is poorly deployed in today's Internet.
-->
Unfortunately, ECN is not widely deployed in today's Internet.
-----
(*) We have updated this in the revised manuscript.
-----
Large amount of Internet TCP trace analysis
-->
A large amount of Internet TCP trace analysis
-----
(*) We have updated this in the revised manuscript.
-----
Reviewer: 2
Comments to the Author
This paper analyzes the impact of the well-known "mice and elephants" problem. It points out that interactive TCP applications may generate "dummy" packets even when they have no packet to send to keep a small response time. As a result, the "statistical multiplexing" of TCP networks is damaged. The gain from the misbehavior has been quantified by analytical modeling and simulations. The authors also propose three sustainable approaches to enhance the performance of interactive applications without adopting the fully-backlogged scheme.
In the last review, I have suggested the authors to do the following modifications. Firstly, I recommended to use only one term for one approach to avoid confusion. The authors have unified the terms. Secondly, I advised that the authors may hope to clarify the simulation scenarios. The authors have done that. Thus, both of my concerns have been addressed.
I also noticed other reviewers' comments. One reviewer complained that the problem is overly exacerbated because the interactive TCP flows only accounts for a small percentage of the Internet traffic. I agree with the point of this reviewer. However, I think the analysis and approaches in this paper may be useful in a case where there are several end users sharing one access link to the Internet. The bandwidth of the access link is limited so that if some of the users adopted the fully-backlogged scheme other users' transmission will be severely affected. The authors may want to present this situation to explain the utility of this paper before it is published.
----
(*) We add a paragraph in the introduction section of the revised manuscript, and explain the utility of our analysis and approaches in other scenarios.
Modification in the paper (Section I):
The analysis and approaches presented in the paper are useful in cases where a single access link is shared among multiple end users. Because the bandwidth of the access link is limited, if a subset of the users adopt the fully-backlogged scheme, other users' transmission is severely affected. Our analysis is equally applicable in such scenarios.
----
Reviewer: 3
Comments to the Author
This paper discusses the problem that interactive tcp flows send dummy packets to improve their response time performance. The authors state that it will significantly jeopardize the Internet's statistical multiplexing principle if all interactive tcp flows
do this, and they propose three approaches.
My comments are as follows:
1) The problem is overly exacerbated. From the simulation results given in Fig.5(a) we can see that the gain is negligible for FIFO and it has negative gain when the loss rate is larger that 0.08.
----
(*) It is only an experimental variation. We rerun the simulations to smooth it out. The simulation script for this experiment is available at http://networks.cs.northwestern.edu/Intcp/new-expt/.
Modification in the manuscript:
We update Figure 5a and 7b with new simulation results.
----
At the same time, when all the interactive TCP send dummy
packets, it will aggravate the congestion and increase the packet loss. This effect needs to be considered when a comparison is made.
----
(*) There are two issues here. First, as we argued in our previous response, a user can only control its own behavior; it has no way to control others. In that context, we have shown that adopting the fully-backlogged approach always improves the performance compared to others for any given background traffic. This means that users always have incentive to adopt the fully-backlogged approach. Second, analysis and experimental data in [morris1997tbm] show that the loss rate increases only by a tiny fraction with increase in the number of fully-backlogged flows sharing a single bottleneck link for a reasonable delay-bandwidth product. As an example, it has been shown in [morris1997tbm] that going from 100 to 200 flows increases the packet loss rate by only 1%, which means that a single user increases packet loss only negligibly, i.e., by 0.01%. Thus, the user sees an immediate improvement in its response time. Hence, from an individual user perspective, it always pays-off to move in this direction.
Reference:
[morris1997tbm] R. Morris. TCP behavior with many flows. In IEEE ICNP '97.
Modification in the paper: We add the following text in the revised manuscript under Section II-B.
When only a single interactive flow is upgraded to a fully-backlogged flow, there is only a negligible or no increase in overall packet loss ratio [22]. Thus, the user sees an immediate improvement in its response time. However, it will aggravate the congestion and greatly increase packet loss when everyone adopts this approach. Indeed, if interactive clients would start taking their bandwidth fair-share, the network would soon become highly congested
[22] R. Morris, "TCP behavior with many flows," in Proceedings of IEEE ICNP '97, Atlanta, GA, Oct. 1997.
----
2) The Authors state that "there are scenarios, such as multiplayer games over the Internet, where users would care about improving their performance relative
to other players, hence reducing their response time."
However, the client source software is the same, so users can not use any method to improve their performance.
----
(*) We agree that modifying the client source software might not always be feasible. Still, a client can modify the kernel TCP stack to achieve the same functionality (as shown in Figure 1 in the paper).
Modification in the paper: We add the following text in Section II-B.
A client can modify the kernel TCP implementation to achieve this functionality.
----
3) The discussion about "sweet spot" is meaningless because the client can not control the loss rate.
----
(*) There are two issues here. First, the client can always drive the system towards a higher loss rate by opening parallel TCP connections, yet being TCP-friendly. Second, when the system is already at a higher loss rate, the client cannot reduce the loss rate as it has no control on others' behavior. Because of this, we remove the Section III-E (Optimizing a Misbehavior Client's Performance) and discussion about "sweet spot" from the revised version of the manuscript.
Modification in the paper:
We remove the Section III-E from the earlier version of the manuscript.
----
===================================================================
Reviewer(s)' Comments to Author:
Reviewer: 1
Comments to the Author
This paper analyzes the influence of the well-known "mice and elephants" problem. It points out that interactive TCP applications may generate "dummy" packets even when they have no packet to send to keep a small response time. As a result, the "statistical multiplexing" of TCP networks is damaged. The gains from the misbehavior has been quantified by analytical modeling and simulations. The authors also propose three sustainable approaches to enhance the performance of interactive applications without adopting the fully-backlogged scheme.
I am glad to see that the authors have made corresponding modifications following my comments. Moreover, they have emphasized that one of the motivations of this research is to guarantee fair transmission between fully-backlogged TCP flows and application-limited TCP flows. This could be a very significant contribution considering that so many people working at home are suffering from their housemates' greedy applications like BT and flashget. I also have a strong interest in the approach II --- Short-term padding with dummy packets. This approach can be realized by Socket application programmers since it does not need to modify TCP Stack in OS kernel. In the context of software engineering, the applicability and low cost will be incentive to a large-scale deployment.
-----
(*) We would like to thank the reviewer for pointing us to potential deployment scenarios of our approaches. We have added couple of sentences in the modified manuscript explaining those deployment scenarios.
Modification in the manuscript (Section-I):
"The analysis and approaches presented in the paper are useful in cases where a single access link is shared among multiple end users. Because the bandwidth of the access link is limited, if a subset of the users adopt the fully-backlogged scheme, other users' transmission is severely affected. For example, many people working at home suffer from their housemates' greedy applications like BitTorrent and Flashget. Our analysis applies to such scenarios as well. The sustainable approaches we discuss towards the end of the paper can be used to improve the performance of the application-limited flows in presence of greedy cross traffic. "
------
Reviewer: 2
Comments to the Author
I still think that the problem is overly exacerbated.
For the comparison, I think that it need consider the increasing of packet loss when all the interactive TCP send dummy packets. As the authors' responds said, "when only a single interactive flow is upgraded to a fully-backlogged flow, there is a negligible or no increase in overall packet loss ratio. however, it will aggravate the congestion and greatly increase packet loss ratio when everyone adopts this approach."
----
(*) There are two issues here. First, we fully agree with the reviewer that the packet loss rate would increase when all the interactive TCP send dummy packets, as we stated in our previous response. Second, we disagree with the reviewer that because of this the problem is overly exacerbated, i.e., that because of increased packet loss rate, clients would have no incentive to apply this approach. What we have shown in the paper is that from the clients' individual perspective, it always pays off to use the fully-backlogged approach, independent from the background packet loss rate (induced by other clients or for any other reason). In other words, a client will always achieve better performance when he/she is applying this approach than when he/she is not applying the approach. We have addressed this issue in the manuscript on page 1, column 2, paragraph 2:
"While the absolute performance of all flows would necessarily degrade in such a case, a troubling observation is that those applying the fully-backlogged approach would still benefit relative to the regular clients. Hence, the dangerous incentive remains."
To further clarify this point, we perform a new experiment and add a new plot in the paper (Figure 6). The figure plots loss rate on the Y-axis and number of fully-backlogged flows in the system on the X-axis. The gap between the solid line and the dotted line depicts the increase in packet loss rate when a client adopts the fully-backlogged approach for a given number of background flows. The experiment is done using a dumbbell topology with access link capacity of 100Mbps and bottleneck capacity of 10Mbps. Each link in the topology has a delay of 2ms.
The figure clearly shows that there is no considerable increase in packet loss rate for any given background setup when a greedy user upgrades itself to a fully-backlogged connection. Given this observation and the fact that an interactive connection always improves its response times by adopting the fully-backlogged approach (Figure 5), any greedy user would be tempted to upgrade itself to fully-backlogged connection; even after it knows that when everyone starts doing the same the overall Internet performance will be severely degraded. This is because there is no central authority that monitors or controls user behavior in the Internet, and a user has no way to know what others are doing. Thus, upgrading itself is the best strategy for a user, and any greedy rational user will do it. The key contribution of the paper is showing that although adopting the fully-backlogged approach can improve a single user performance, it severely degrades the overall performance of the network when everyone adopts this approach rather than just claiming that interactive users can improve their performance by adopting fully-backlogged approach. Thus, we explore alternative approaches which have less overhead and achieve comparable improvement in response times.
Modification in the manuscript (Section-III):
"In order to understand the impact on overall network performance when a user adopts the fully-backlogged approach we conduct an experiment and present our observation in Figure 6. The experiment is done using a dumbbell topology with access link capacity of 100Mbps and bottleneck capacity of 10Mbps. Each link in the topology has a delay of 2ms. Figure 6 shows the overall loss rate on the Y-axis and number of fully-backlogged flows in the system on the X-axis. The gap between the solid line and the dotted line depicts the increase in packet loss rate when a user adopts the fully-backlogged approach for a given number of background flows on X-axis.
Figure 6 clearly shows that there is no considerable increase in packet loss rate for any given background setup when a user upgrades itself to fully-backlogged connection. Given this observation and the fact that an interactive connection always improves its response times by adopting fully-backlogged approach, any greedy user would always be tempted to upgrade itself to fully- backlogged connection, even after knowing that if everyone starts doing the same the overall Internet performance will be severely degraded. This is because there is no central authority that monitors or controls user behavior in the Internet, and a user has no way to know what others are doing. Thus upgrading itself is the best strategy for a user, and any greedy rational user will do it."
----
Reviewer: 3
Comments to the Author
Review of paper with title: Upgrading Mice to Elephants: Effects and
End-Point Solutions
For IEEE Transactions on Networking,
by Amit Mondal and Aleksandar Kuzmanovic
P1
--
"loosing memory" -> "losing memory"
(*) We have updated this in the revised manuscript.
(loose is an adjective which means nearly falling off or falling
out, eg "loose screw")
Moreover, inciting servers to send traffic at TCP-fair rates is not
impossible [12]. --> Moreover, inducing servers to send traffic at
TCP-fair rates is not impossible [12].
(*) We have updated this in the revised manuscript.
P2
Because Drop Tail queues invoke correlated packet losses, the
corresponding gain is smaller. --> Because Drop Tail queues induce
correlated packet losses, the corresponding gain is smaller.
(*) We have updated this in the revised manuscript.
Because the bandwidth of the access link is limited, if a subset of
the users adopt the fully-backlogged scheme, other users
transmission is severely affected. Our analysis is equally
applicable in such scenarios.
-->
Equally applicable to what?
(*) We have updated this in the revised manuscript.
"Our analysis applies to such scenarios as well."
avoid loosing memory in moments of data starvation [8].
-->
avoid losing memory in moments of data starvation [8].
(*) We have updated this in the revised manuscript.
P4
Eqn (6) is not correct. This eqn says that the E() operator and the
\hat Q function commute. But this is almost certainly not the case,
because the function Q() is nonlinear.
This eqn could hold as an approximation, but it is not exact.
(*) We change the equal sign to approx sign.
Eqn (8): what is the justification of this eqn? Where is it? Some
evidence must be given.
(*) We change the text as follows:
"according to [15], the probability that a loss indication is a timeout becomes
"
p5
To verify our modeling results, we conduct extensive simulation
experiments. -->
To verify our modeling results, we have conducted extensive
simulation experiments, which are described here.
(*) We have updated this in the revised manuscript.
P6
The figure shows deviation in model output from simulation results.
-->
The figure shows a discrepancy between the model and the
simulations.
(*) We have updated this in the revised manuscript.
incorrectly assumed loss when in fact the data or ACKs are merely
delayed.
-->
incorrectly assumed lost when in fact the data or ACKs are merely
delayed.
(*) We have updated this in the revised manuscript.
one argument on its behalf is that interactive applications
-->
one argument in its behalf is that interactive applications
(*) We have updated this in the revised manuscript.
P7
Anyhow --> At any rate
(*) We have updated this in the revised manuscript.
A timeout is invoked if two or less dummy packets
-->
A timeout is invoked if two or fewer dummy packets
(*) We have updated this in the revised manuscript.
Diversity --> Redundancy
(*) We opt to retain the name "Diversity approach" for our approach-III.
===================================================================
Reviewer(s)' Comments to Author:
Reviewer: 1
Comments to the Author
(There are no comments)
Reviewer: 2
Comments to the Author
Review of paper with title: Upgrading Mice to Elephants: Effects and
End-Point Solutions
For IEEE Transactions on Networking,
by Amit Mondal and Aleksandar Kuzmanovic
Detailed suggestions
------------------------
P3
--
We assume independent packet losses [16] [18]
--> [please indicate why you are citing these references. You should
give a reason why independence is a reasonable assumption and use
the citations to justify the assumption, not just cite and imply
that there is some justification.]
(*) We add the following text in the manuscript.
"While packet losses in a Droptail queue might be correlated within a RTT round, packet losses are independent among different rounds [18]. Given that interactive applications typically send only a single packet in a round, the independent packet loss assumption is reasonable for both RED and Droptail queues."
In equation (3), the expression inside brackets appears to be
unnecessarily complicated. Why not just p/(1-2p) ?
(*) We simplify the expression as pointed out by the reviewer.
P4
--
Denote by b the number of packets acknowledged by each
--> Denote by b the average number of packets acknowledged by each
[?]
(*) We have updated this in the revised manuscript.
Denote by w the TCP congestion window size
--> [In what units? I assume bytes, because b is in bytes but this
is not obviously right. Even if this "should" be obvious, omitting
it slows down the reader and creates uncertainty.]
(*) w represents window size in packets.
We have updated this in the manuscript.
Modification in the manuscript:
"Denote by w the TCP congestion window size in packets
"
Next, considering a uniform distribution of the TCP congestion
window W, on the discrete interval [0,wmax];
-->
Next, assuming a uniform distribution for the TCP congestion window
W, on the discrete interval [0,wmax];
(*) We have updated this in the revised version of the manuscript.
P6
--
In order to make a comparison !?!?!
--> [This is a rather inadequate explanation of what follows. It
would be more reasonable to say: In order to understand why the
match between theory and simulations shown in Figure 5(a) is so
poor.
(*) We change the text as suggested by the reviewer.
Also, the model with random packet losses appears to be using RED,
but I don't see anywhere in the paper where this is explained. Also,
why is a similar experiment not conducted for the Droptail queue
discipline?
(*) We add the following text in the revised version of the manuscript.
"We apply RED queue at the routers for this experiment. Given that packet loss is introduced artificially, and there is no congestion in the network, both RED and DropTail yield similar results."
More fundamentally, it appears that the match between theory and
simulations shown in Figure 5(a) is surprisingly poor. Ideally this
should be addressed by improving the theory. Eg if the explanation
is correct, that "This is due to varying queuing delay in
simulations, and because the effective RTT increases" then this
should be taken into account in the theory. This observation offers
a much better check on the validity of the theory because the RTT
can be individually estimated in each simulation and used in
combination with the theory. This could then validate the theory in
a more meaningful way than the approach which has been used.
Alternatively, at least, the reader should be given some explanation
for why the poor accuracy of the theory is not a problem.
(*) Incorporating varying RTT into the modeling becomes increasingly complicated. However, we add the following text in the revised version of the manuscript.
"Despite the mismatch between the modeling and simulations, the gain ratio is always greater than one both for RED and Droptail queues. The important implication is that greedy users always have the incentive to adopt the fully-backlogged approach to improve their response times."
One last thing: the distinction between model, theory (a prediction
of performance based on the model), and simulation should be
maintained throughout. At present the word model is used
synonymously with theory in some places.]
(*) We have changed everything to modeling in the revised version of the manuscript.
P7
--
Nevertheless, the results we present below make such a discussion
obsolete. --> However, the results we present below make such a discussion
obsolete.
(*) We have updated this in the revised version of the manuscript.
p8
--
At the bottom it appears that congestion windows are being measured in
packets, not bytes. Hence the concern that earlier this was not
clear is valid.
(*) In the revised version of the manuscript, in section III-B, we explicitly mention that congestion window is measured in packets. Hence, we expect no confusion at this point.
At the bottom of p8, left col, is the minRTO figure given here
actually minRTO'?
P8, Col 2
(*) We have updated this in the revised version of the manuscript.
---------
Figure 7 plots the expected latency as a function of the packet loss
ratio for the three approaches.
-->
Figure 7 plots the expected latency, estimated by the analyses given
above (list equations), as a function of the packet loss ratio for
the three approaches.
(*) We have updated this in the revised version of the manuscript.
Since padded dummy packets are smaller than data packets, the
likelihood that they will get dropped at the byte-based drop-tail
queue is smaller. --> [This also provides an explanation for why the
assumption that packet losses are independent, used above, is
reasonable. Hence it should be mentioned there, as a justification.
However, surely the different probability of loss for small packets
could be estimated, using ns2. It should not be difficult to do
this, so it would enhance the paper to do these simulations and
report. In fact, the simulations could be just the ones already
used, but with packet loss vs packet size also reported.]
(*) We do a new experiment, and add the following text and Figure 10 in the revised version of the manuscript.
"To validate the hypothesis, we conduct an experiment where we generate multiple Telnet flows, and each of them uses a different segment size (128, 256, 512, and 1024 bytes). The bottleneck router uses a Droptail queue in the byte mode. We control the network load by generating pareto and http cross traffic of average segment size of 576 bytes. Figure 10 shows the impact of the packet size on the observed loss rate experienced by the flows. It clearly shows that flows with smaller segment sizes experience significantly lower loss rates relative to the flows with larger segment sizes."