Hi all,
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.
Summary:
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.
Technicals:
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.
Section 7.1:
[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
Section 7.2:
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.
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.
Kind regards,
Martin
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring