This got lost on my end, sorry for this. The filter just moved these
messages out of my sight... :-/
Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
Sorry for late reply. Please see some comments inline[Gaurav]
On Jan 9, 2018, at 2:25 PM, Martin Stiemerling <mls.i...@gmail.com
I've reviewed this document as part of the transport area review
team's ongoing effort to review key IETF documents. These comments
were written primarily for the transport area directors, but are
copied to the document's authors for their information and to allow
them to address any issues raised. When done at the time of IETF Last
Call, the authors should consider this review together with any other
last-call comments they receive. Please always CC tsv-art@… if you
reply to or forward this review.
This draft has serious issues in Section 7.1, 7.2 and in one part of
Section3, described in the review, and needs to be rethought. The
other sections are good AFAIK.
The overall draft looks ok, but the three points below look strange
and need a fix before publication IMHO:
Both Sections, 7.1. and 7.2., are describing ideas, but not well
proven funcationality and not even safe to use functionality. Both are
some sort discussing that different paths in the network could be used
by the end host traffic. This sounds pretty much like the Path Aware
Networking Proposed Research Group (https://irtf.org/panrg) and hints
to the fact that there is no commonly understand and accepted
engineering solution in this space.
[KANDULA04] is a really old reference that hasn't been followed up in
recent times and even worse there is no evidence that this is going to
work good enough or stable enough under real Internet traffic.
Additionally, it is more than unclear how any modern TCP
implementation will react to this
[Gaurav] Will get back on this.
I will reply to the other email dicussing this.
[Gaurav] I believe Authors are trying to highlight that Host which is
influence the traffic based on the Calculations locally or jointly with
the controller. Implementations can decide how much Centralized -vs-
localized control is allowed at Host based on performance data collection.
This section describes an idea without detailing too much about any
further aspects. Further it changes the commonly accepted notion of
what an end host can do with the network. At best this would require a
good definition of what an end host in your setting is, e.g., a highly
modified piece of (at least) software that usually not found in OS
availble on the market (yet?)
Further communicating instantaneous path characteristics to a central
point is potentially a bad idea, as the data is already outdated when
reported by any node.
Performance data collection (monitoring?) isn't crucial when it comes to
timely (actually real-time) reaction. However, this section isn't just
about performance data collection as it is about "Performance-aware
routing" this seems to try to interact in real-time with the network
behavior of TCP. This isn't even close to acceptable.
I would be ok to say that it is useful to collect performance data for
offline analysis and improvement of the data network. However, this is
at completely different magnitues of time scales.
I would recommend to remove the TCP part from this section entirely.
[Gaurav] Martin, Authors are trying to suggest that TCP is rightly
treating Network as Black Box. Authors are implying per path performance
metrics as not cached. Is there some change in text you are suggesting?
Section 3, 3rd bullet point:
It is the foundation of TCP that the network is regarded as a black
box and that you infer from the transmission of packets what the
current state of the network path is. Inferring network path metrics
(you mention SRTT, MSS, CWND ) is a bad idea, as this would required
that all paths exhibit this and if not what is going to happen?
It could be an interesting research field to change many points in
TCP's behavior, but this once again points to the fact that this not
the IETF works but IRTF or elsewhere.
I would recommend to remove the 3rd bullet point completey. TCP isn't
the place to remember "good" or "bad" paths. This is something the
network could decide, e.g., rerouting TCP flows within the network or
changing the forwarding path in the network for particular flows (if it
is not routed).
spring mailing list