Re: [Tsv-art] [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08

Hi, Martin,

Friendly Reminder for your feedback to close this review.

Cheers,

Gaurav

On Thu, Mar 1, 2018 at 7:01 AM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:

> Hey Martin,
>
> Seeking your feedback here. Regarding Section 7.1, The intent of the
> document is to describe one suggestive way and do not attempt to
> standardize any suggested mechanisms based considering the Informational
> nature. Authors do not attempt to fully solve – but to indicate how SR
> helps towards this.The details of how the hosts figure out what paths to
> take through the network such that the TCP and application are not affected
> is outside the scope of this document.
>
> Would you prefer to add perhaps - “details outside the scope” or “this is
> one of the ways” or something else?
>
> Cheers,
>
> Gaurav
>
>
> On Wed, Feb 14, 2018 at 8:47 PM, Gaurav Dawra <gdawra.ietf@gmail.com>
> wrote:
>
>> Hey Martin,
>>
>> Sorry for late reply. Please see some comments inline[Gaurav]
>>
>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling <mls.ietf@gmail.com>
>> wrote:
>>
>> 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
>>
>> [Gaurav] Will get back on 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.
>>
>> [Gaurav] I believe Authors are trying to highlight that Host which is
>> defined in (https://tools.ietf.org/html/draft-ietf-spring-segment-routi
>> ng-15) can 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.
>>
>>
>> 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.
>>
>> [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?
>>
>> Cheers,
>>
>> Gaurav
>>
>>
>> Kind regards,
>>
>>  Martin
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>>
>>
>