Dear Tom,
The review of your paper is complete, and I am attaching a copy of the
reviewer's comments. Your paper requires almost no changes, however, we
ask that [based on the review] you make the necessary changes. Please
write a brief explanation of the changes you've made, any that you
couldn't make and send them to me. We must receive your revised paper
*no later* than TUESDAY, NOVEMBER 10TH.
If you have any questions, please feel free to contact me. I look
forward to receiving your revised paper very soon.
Kind regards,
Kersten Barney
****************************************************************
This paper is in very good shape and I have no problem with its
publication. The treatment of the routing and path-induced loss and
latency phenomena seems well reasoned. The proposed cure (engineered
tunnels) is more than a little speculative, but as a motivation for
further exploration and measurement of this approach, the paper succeeds
admirably.
I have a few minor editorial and technical comments, which should be
addressed before publication:
- P1, second column, second paragraph, the last sentence is missing a
verb. It should probably read "The result is lost productivity while
users..."
- P2, second column, while you distinguish your approach from naive TCP
tweaks which penalize cooperative users in favor of greedy users, you do
not compare your approach to a number of obvious alternatives such as:
- reconfigure the L2/L1 net (e.g. ATM engineered VCs, Sonet ring
reconfiguration) based on long term measurements to provide engineered
connectivity.
- MPLS/Tag switching to dynamically create L2 cut-through paths
for
popular destination.
I don't necessarily argue that L2 or L2/L3 mechanisms are a better
approach than L3 tunnels (I personally believe they aren't), but I think
for completeness they should at least be mentioned. Given that the
Detour tunnels have to be engineered by hand as well, it isn't
immediately obvious what the advantages are.
- P3, second column, third paragraph (starting with "A number of
factors"). I had a bit of difficulty following the flow from here to the
end of the page. The discussion is meant to show why the measurements
are an underestimate, yet it wasn't clear to me (for example) why the
traversal of a host link twice should matter since host/router
conenctions tend to be much faster and less loaded than any of the
bottleneck links.
One small additional point is at the end of the paragraph you refer to
the "change during our measurement period" and it isn't clear whether
you are referring to the 15 minute mean measurement interval, or the
entire 35 day measurement session. If the latter, I'm not sure I should
draw any path-related conclusions, since with the net growing so fast I
would be surprised if over that period paths *didn't* change!
- P3, second column, bottom. One nagging doubt in my mind about the
analysis methodology is that you are comparing the observed rates of two
paths carrying different traffic and asserting that if you moved some of
the traffic from the more congested to the less congested things will
get better. For this to be unconditionally true, two additional criteria
have to be established:
a) the two paths are in fact disjoint (disjointness at L3 is certainly a
necessary condition, but not a sufficient condition, since there may be
paths shared at L2 via an ATM ABR service or other phenomena)
b) the less congested path, when loaded with the additional traffic,
will congest no more than the congestion relieved by removing the
traffic from its current path. There is some intuition to support this,
but there's enough non-linear behavior in the current internet that the
linearity assumption should at least be tested.
- p4 , first column, discussion of background drop rates. I don't think
you sufficiently motivate why this matters: why does a connection need
to distinguish whether a drop is caused by its own behavior or that of
other connections? In some cases it doesn't (e.g. the peak rate of the
connection's flow does not exceed the bandwith of the bottlneck link) so
you need a bit more explanation here.
- p 7, first column about 1/3 of the way down, end of line,
missing "e" from "Th"
[End of Review]
-- ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*Kersten Barney Administrative Associate Asst. to Profs. David Dill & Nick McKeown Computer Systems Laboratory Gates Building 3A, Room 351 Stanford University Stanford, CA 94305-9030 (650)725-9077 (650)725-6949 fax email: kersten@csl.stanford.edu ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*