Telechat Review of draft-ietf-spring-segment-routing-msdc-08
review-ietf-spring-segment-routing-msdc-08-tsvart-telechat-stiemerling-2018-01-09-00

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