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

From: Alvaro Retana <[email-masked]>
Date: Fri, 6 Apr 2018 11:59:23 -0700

[Adding Mirja to this thread, since she is the AD holding the DISCUSS on
this document.]

Mirja:

Hi!

Please take a look at the thread below — I still haven’t seen a reply from
Martin.

Thanks!

Alvaro.

On March 9, 2018 at 7:23:28 AM, Gaurav Dawra ([email-masked]) wrote:

Hi, Martin,

Friendly Reminder for your feedback to close this review.

Cheers,

Gaurav

On Thu, Mar 1, 2018 at 7:01 AM, Gaurav Dawra <[email-masked]> 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 <[email-masked]>
> wrote:
>
>> Hey Martin,
>>
>> Sorry for late reply. Please see some comments inline[Gaurav]
>>
>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling <[email-masked]>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>>
>>
>

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 9 Apr 2018 16:58:34 +0200

Hi Gaurav,

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:
>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling <[email-masked] 
>> <mailto:[email-masked]>> 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:
>> 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:
>> 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

I will reply to the other email dicussing this.

>> 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?)
> defined in 
> (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-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.

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.

>> 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).

Kind regards,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 9 Apr 2018 17:02:18 +0200

Hi Gaurav,

Am 01.03.18 um 16:01 schrieb Gaurav Dawra:
> 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?

Since the cited paper is really old and there is no up-to-date proof of 
any working implementation with real Internet traffic: Please remove 
this part.

This will require a lot of theoretical work, discussions the transport 
community, discussions with operating system vendors and testing in the 
wild open Internet.

Kind regards,

   Martin