Let me know if you have any questions,
Amin
----
1. Introduction
Paragraph 1: I agree with Stefan that the last sentence (wars, disease,
and famine) is a bit much. It is well crafted but tough to swallow.
Paragraph 3: Suggest "can be outrageously slow or completely
unavailable." in second to last sentence. I might replace
"outrageously" with "very".
Grammer in next sentence: The result *is* lost productivity...
Pragraph 4: I do not like the rhetorical question style. Suggest
starting with: "It is difficult to determine the exact cause of Internet
slowdowns because of the difficulty of measuring the Internet. However,
it is clear that a number of assumptions have changed..."
Paragraph 6: "recipe for disaster" is a little strong.
Paragraph 9: It is difficult to where this paragraph is going. The
topic sentence proposes constructing a virtual Internet, but then the
concluding sentence says that this is not a good long term solution. I
think the actual contributions are somewhere in the middle of the
paragraph (routing around performance bottlenecks, smoothing traffic,
and active measurement).
2. Routing Inefficiencies
I thought this section was well quite well done overall.
I do not understand the bullet on problems with "Single path routing"
(This should be "Single Path Routing" to stay consistent with the
capitalization of the other bullets). You somehow relate this to the
previous bullet, but then don't explain why it is a problem in
isolation. I think you want to say "there are usually multiple paths
between two hosts. Current routing algorithms will statically choose
one of the available paths for transmission. This selection is adjusted
too infrequent, and at too coarse a granularity... It would be better
to utilize all available paths with an intelligent function for
determining the distribution of load among available paths."
First paragraph after bullets: "examined only the last record of the
traceroute output, thereby avoiding well-known biases with ICMP
processing in Internet routers. We also filtered our data to eliminate
hosts which rate limit ICMP responses." I think that the three points
are opaque to the typical reader (last record of traceroute output?
*well-known* biases? hosts that rate limit ICMP?
Second paragraph: you seem to contradict the previous paragraph by
saying "the average of the three samples" Didn't you just say you only
look at the last record of traceroute output?
Third paragraph: This is a disclaimer paragraph. It should come either
at the beginning of the discussion or at the end, but definitely not in
the middle. I suggest moving it down to the end of the section.
Fifth paragraph: last sentence should read "the improvement is *a*
factor of six or better". Also, this is pretty impressive. You might
want to build up this point a little bit more.
3 Transport
This section should be called "Transport Inefficiencies" to parallel
section 2.
I got lost when I started reading this section, because I could not
figure out where the paper was going at this point. After looking
through the paper for a minute, I realized that section 2 and 3 are
really "Motivation" for the architecture described in section 4. They
are just not labelled that way. So, I would suggest putting in a little
roadmap at the beginning of the first paragraph. Something like "The
previous section describes current problems with Internet routing. In
this section we describe a number of problems with current Internet
transport protocols leading to a proposed system architecture for
addressing both classes of inefficiencies in Section 4."
Paragraph 2: I suggest inserting a sentence giving more credit to Van in
this paragraph. Before ripping apart TCP, you should say something like
it has held up very well, is well designed, etc. but changes in Internet
traffic characteristics have introduced a number of inefficiencies.
Figure 3: The light dots (representing best alternate route) are hard to
read. I don't know if you can do anything about this though.
Paragraph 3: I would not reference Stevens94 (strange to reference a
book, plus you go through the major characteristics in the following
bullets).
One question that is likely to occur to readers as they read this
section is how HTTP 1.1 will interact/does interact with the arguments
you are making. A lot of the problems you mention seem to arise
directly from "short flows", but this will become less of a problem once
1.1 is widely deployed. Now, I know that all the techniques are still
valid, but it seems like you should pre-emptively mention issues with
HTTP 1.1 before you get the question from readers.
The point of sections 3.1-3.3 is to show that it is quite likely that
you will only get 75 kbps over a 10 mbps link. However, I do not think
that you spend enough time going through why this happens. For example,
it is jarring to bring in padhye98 and, without any further explanation,
say that bandwidth drops to 228 kbps.
Similarly, section 3.3 seems to have a new result for bounding BW that
Neal and Stefan came up with. Again, I do not get enough of a sense of
where all the numbers come from. I think further explanation is
warranted if this is a new result being presented in the paper.
Section 3.3, paragraph 5: first sentence should be "Many TCP
implementations have limitations addressing the interaction of slow
start and ..." I believe the third sentence should read "If no
**addtional** data arrives before..." Last sentence should be "an
average of 100 ms for the **receiver's** delayed acknowledgment timer to
fire.
section 3.3, paragraph 6: Strange having a one sentence paragraph.
Also, it still felt like it came out of nowhere. I think you want a
little more explanation than "incorporating these three effects".
Section 3.3, paragraph 8: first sentence should read "two orders of
magnitude less bandwidth *than* theoritically possible with a sliding
window algorithm, and two orders of magnitude less bandwidth **than
available over a typical 10 mbps LAN.**" Still strange having a one
sentence paragraph (and a fairly long one at that).
Section 4
Paragraph 1: second setence should read "The enormous heterogeneity and
scale *makes* it difficult to anticipate the global effects of *new
algorithms* and also *makes it difficult to deploy new algorithms
globally.*"
Figure 5: figure should read "a 546 byte MSS *as a function of packet
drop rate.*" For both figure 4 and 5, you may want to mention how you
simulated the results (ns, etc.).
Paragraph 4: "*The Detour* architecture is illustrated in Figure 6."
Section 4.1, paragraph 1. First sentence: eliminate "obvious" (e.g.,
"one opportunity is to use real"). You mention how the initial ARPANET
tried to do this and failed. I think that you need to do more than
reference bresalu95 to describe why it can work today. This is a key
point!
Section 4.1, paragraph 2. The last sentence is pretty wishy-washy, you
use the phrases "Ideally... we hope ... and we may" in the same
sentence. Maybe "We may be able to automatically load balance our
system and avoid congestion before it occurs by randomly assigning flows
to good paths and by dynamically varying how traffic is spread across to
such paths."
Section 4.2, paragraph 1: "TCP behavior in Section 3 *suggests* that"
Also, "small number of samples *to* derive the statea of the network."
Section 4.2, paragraph 2: "A Detour router at the edge of the network
can observe many difference flows, and thus it can improve the accuracy
and fairness of the underlying transport mechanism by sharing aggregate
flow information."
Section 4.2, paragraph 3: Again, HTTP 1.1 immediately pops to mind as a
counterpoint to the problems you describe. Is the problem TCP/the
Internet, or a poor choice of protocols on top of TCP?
Section 4.2, paragraph 4: "These packet drops and consequent retransmits
could be reduced or avoided *by informing the host* about the fair share
of the bottleneck." Also, "initiate slow start with *an appropriate
window size*."
Section 4.2, paragraph 5: This concluding paragraph comes out of
nowhere. It seems to be an interesting/valid point, but it is missing a
transition.
Section 5
First sentence: is it just the web that has caused growing pains? Some
would argue that the Internet has had to deal with growing pains
throughout its history and the Web is just the latest examples. Still
others would argue that the Internet has held up remarkably well. I
think you did a better job in the intro of saying, "The Internet has
done great, but we can do better".
Further down, "... we will need to *implement* congestion control
strategies that do not require ..."
Also, "*The perennial challenge facing the Internet is fixing*
scalability and performance problems as they appear, while still
providing robust service."