Reviewer 1 Comments:
This paper proposed a transport protocol for low-priority service,
TCP-LP, to use the excess bandwidth in the network. TCP-LP uses
one-way packet delays for early congestion indications. I think this
is a strong and fairly thorough paper, and I would recommend it for
acceptance by Transactions on Networking. I have some rather minor
feedback to the authors below.
The smoothing parameter:
If the smoothing parameter is a fixed constant, such as 1/8, then the
average one-way delay might be averaged over multiple round trip times
when the congestion window is small, but averaged over a small
fraction of a round-trip time when the congestion window is large. Is
this the behavior that is intended? If one-way delays are measured for
every packet, it would seem reasonable to me for the smoothing
parameter to be a function of the congestion window, so that the
average delay is computed over a fixed time period in RTTs, regardless
of the congestion window. (The same criticism applies to TCP's current
computation of the smoothed round-trip time when timestamps are used.)
It would be useful to discuss difficult scenarios for TCP-LP or for
other low-priority transport protocols based on delay as early
congestion indications. Examples of such scenarios include connections
over wireless links with variable delay; or connections that use
multiple paths. (Of course, the worst that would happen in a difficult
scenario would be that TCP-LP would be as aggressive as standard TCP,
or would fail to make use of available bandwidth.)
It is clear that the use of one-way packet delay in TCP-LP has
advantages of the use of two-way packet delay, but are there any extra
costs incurred by TCP-LP, relative to, say, TCP Nice?
I like it that the ns code and simulation scripts are publically
Reviewer 2 Comments:
This paper designs an TCP congestion control algorithm, called TCP-LP,
to give a low-priority service to some flows. The algorithm uses delay
as an indicator of congestion which allows it to react before
traditional TCP congestion control. Furthermore timeouts are used to
ensure that TCP-LP gives priority to TCP flows. Some analysis is given
to motivate why TCP-LP should be unintrusive to TCP flows.
Simulations and experiments are then presented to support the claims
that TCP-LP is unintrusive to TCP flows, does not significantly
increase delay for interactive traffic, and shares fairly between
TCP-LP flows, while remaining able to use available bandwidth.
The algorithm design is well motivated and described. To the best of
my knowledge using delay to separate priorities is a nice contribution
here. While the authors recognise the salient points about \delta and
RTT ratios, the itt variable is set heuristically.
However the performance evaluation has several details that should be
- the scale parameter of the Pareto distribution should be stated on
- it would be good to know that the HTTP response time simulations use
the same sample path of file sizes and think times; otherwise the
result is weaker.
- It is also difficult to understand the simulation setup for HTTP
flows; is there only one user or multiple users? From the results I
suspect there is one user on the 1.5Mb pipe; I think the results would
differ if there were multiple users because then the 1.5 pipe would
always have competing long lived TCP traffic.
- The binding of multihop congestion with RTT is poor; it is difficult
to untangle the effects of RTT and multiple congested links.
- The RTT of the experimental testbed is not stated; this would help
to understand the results.
My only problem with the performance evaluation is the claim that HTTP
response times are significantly affected by TCP-LP. This will depend
more on weather there is competing TCP traffic than whether TCP-LP is
used. In a web traffic mix it is just as likely that there will be
competing long-lived TCP flows. I admit its better but the claim seems
stronger than it should be.
Several little presentational points would improve the paper:
- The flow of paragraphs 1,2,3 in section III-B.2 is a little
confusing. The first claims that reacting similarly to TCP-ECN is too
slow. The second seems to suggest that it will react to each packet
(clearly too fast). The third then seems to suggest that it will in
fact react slower that TCP-ECN. Perhaps leading the reader more
clearly would be nice.
- pg5 seems to use Q \delta and \delta Q , its nice to have the same
order for the same term.
- all the graphs are small (maybe they have to be), however fig 14,
17, 20 are just too cluttered. The X and + marks are fairly
indistinguishable which makes them visually meaningless for driving
any kind of point home. Perhaps splitting them into separate (larger)
graphs, or even losing them and having error bars would be better.
- web address in second paragraph spills into next column on page 11.
Reviewer 3 Comments:
This paper proposed a protocol to utilize the unused bandwidth left by
regular TCP traffic, while not intrusive to regular TCP traffic. This
protocol is an interesting and useful protocol. For example, it can be
used to background transport files.
The key idea is how to estimate the available bandwidth, or more
exactly, how to determine whether there is available bandwidth or not.
There are already some proposed methods to estimate the available
bandwidth, which usually uses non-TCP traffic, and take at least
multiple RTTs to get the result. Those bandwidth estimation techniques
usually use the increasing pattern of delay as an indication that no
available bandwidth is left. This paper propose to use the threshold
to determine whether bandwidth is available or not, while using only
Another important feature of this protocol is that it measures only
the one-way delay instead of round-trip delay, since RTT is sensitive
to the reverse traffic. To get the one-way delay, time stamp option is
required, but it is not a big problem.
The authors give detailed analysis, simulation, and experiment result
for this protocol, which prove that this is a good protocol.
Overall, I recommend that this paper is accepted to be published. Even
though I think there is a problem with this protocol. In a multi-hop
network, using a threshold between the min and max delays to measure
the available bandwidth may not be a good way. For example, the max
delay could be very large at some time, and hence the average delay is
below the threshold in most cases. I did observe this happened in some
of my simulations.