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

[Alvaro Retana <[e-mail]>]

Thanks Martin!

On June 6, 2018 at 3:14:45 PM, Martin Stiemerling ([e-mail])
wrote:

Hi Alvaro, all,

Thanks for addressing my concerns.

This version is good to go from my side.

Kind regards,

;Martin

Am 30.05.18 um 21:55 schrieb Alvaro Retana:
> Martin:
> br/>> Hi!!  How are you?
> br/>> Gaurav just posted a revision.  Please takke a look and let us know
if br/>> the changes address your concerrns or not.
> br/>>
https://www.ietf.org/rfcdiff??url2=draft-ietf-spring-segment-routing-msdc-09
> br/>> Thanks!!!
> br/>> Alvaro. <
> br/>> On May 25, 2018 at 12:08:46 PM, Gaurav Dawra (([e-mail]
br/>> <mailto:gdawra.ietf@@gmail.com>) wrote:
> br/>>> Hi Martin, <
>>
>> Thanks for review. I will post the new version. Hopefully, it will
br/>>> address all your comments and we can close thhis review.
>>
>> Any updates on below response?
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>> On May 23, 2018, at 4:17 AM, Gaurav Dawra <[e-mail] br/>>>
<mailto:gdawra.ietf@@gmail.com>> wrote:
>>
>>> Hi Martin,
>>>
>>> Thanks for the review. Any further comments here ? I will post the
br/>>>> new version soon. <
>>>
>>> Cheers,
>>>
>>> Gaurav
>>>
>>> Sent from my iPhone
>>>
>>> On May 16, 2018, at 7:44 PM, Gaurav Dawra <[e-mail]
br/>>>> <mailto:gdawra.ietf@@gmail.com>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> Apologies from my end we had few internal authors conversations on
br/>>>>> the points you have raised. <
>>>>
>>>> Please find below my response. I will be happy to discuss further,
br/>>>>> if needed. <
>>>>
>>>> <Gaurav> inline...
>>>>
>>>>> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <[e-mail]
br/>>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>> Hi Gaurav,
>>>>>
>>>>> This got lost on my end, sorry for this. The filter just moved
br/>>>>>> these messages out of my sight... :-/
>>>>>
>>>>> Am 15.02.18 um 05:47 schrieb Gaurav Dawra:
>>>>>> Hey Martin,
>>>>>> Sorry for late reply. Please see some comments inline[Gaurav]
>>>>>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling br/>>>>>>>>
<mls.ietf@@gmail.com <mailto:[e-mail]> br/>>>>>>>>; <mailto:
[e-mail]>> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I've reviewed this document as part of the transport area review
br/>>>>>>>> team's ongoing effort to review key IETF documents. These
br/>>>&gtt;>>>> comments were written primarily for the transport area
directors, br/>>>>>>>> but are copied to the doocument's authors for their
information br/>>>>>>>&> and to allow them to address any issues raised.
When done at the
>>>>>>> time of IETF Last Call, the authors should consider this review
br/>>>>>>>> together with any other last-call comments they receive. Please
br/>>>&>>>>> 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
br/>>>>>>>> of Secction3, described in the review, and needs to be
rethought. br/>>&>>>>>> The other sections are good AFAIK.
>>>>>>>
>>>>>>>
>>>>>>> Technicals:
>>>>>>> The overall draft looks ok, but the three points below look
br/>>>>>>>> strange and need a fix before publication IMHO:
>>>>>>>
>>>>>>> Both Sections, 7.1. and 7.2., are describing ideas, but not well
br/>>>>>>>> proven funcationality and not even safe to use functionality.
br/>>>&>>>>> Both are some sort discussing that different paths in the
network br/>>>>>>>> could be used by the eend host traffic. This sounds
pretty much br/>>>>>>&gtt;> like the Path Aware Networking Proposed
Research Group br/>&gtt;>>>>>> (https://irtf.org/panrg) and hints to the
fact that there is no br/>>>>>>>> commonly understannd and accepted
engineering solution in this space.
>>>>>>>
>>>>>>> Section 7.1:
>>>>>>> [KANDULA04] is a really old reference that hasn't been followed
br/>>>>>>>> up iin recent times and even worse there is no evidence that
this br/>&gtt;>>>>>> is going to work good enough or stable enough under
real Internet br/>>>>>>>> traffic. Additioonally, it is more than unclear
how any modern TCP br/>>>>&ggt;>>> implementation will react to this
>>>>>> [Gaurav] Will get back on this.
>>>>>
>>>>> I will reply to the other email dicussing this.
>>>> <Gaurav> I have replied to other thread.
>>>>>
>>>>>>>
>>>>>>> Section 7.2:
>>>>>>> This section describes an idea without detailing too much about
br/>>>>>>>> any furtther aspects. Further it changes the commonly accepted
br/>>>;>>>>> notion of what an end host can do with the network. At best
this br/>>>>>>>> would require a good ddefinition of what an end host in
your br/>>>>>>>&ggt; 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
br/>>>>>>>> central point is potentially a bad idea, as the data is already
br/>>>;>>>>> outdated when reported by any node.
>>>>>> [Gaurav] I believe Authors are trying to highlight that Host which
br/>>>>>>> is defineed in br/>>>>>>> (
https://tools.ietf.org/html/draftt-ietf-spring-segment-routing-15)
br/>>>>>>> can innfluence the traffic based on the Calculations locally or
br/>>&gtt;>>>> jointly with the controller. Implementations can decide how
much br/>>>>>>> Centralized -vs- localized coontrol is allowed at Host
based on br/>>>>>>> perfoormance data collection.
>>>>>
>>>>> Performance data collection (monitoring?) isn't crucial when it
br/>>>>>> comes to timely (actuaally real-time) reaction. However, this
br/>>>>>> secttion isn't just about performance data collection as it is
about br/>>>>>>> "Performance-aware routing" this seems to try to interact
in br/>>>>>> real-time with the network behhavior of TCP. This isn't even
close br/>>>>>> to acceeptable.
>>>>>
>>>>> I would be ok to say that it is useful to collect performance data
br/>>>>>> for offline analysis and improvement of the data network.
However, br/>>>>>&ggt; this is at completely different magnitues of time
scales.
>>>>>
>>>>> I would recommend to remove the TCP part from this section entirely.
>>>> <Gaurav>Ack, will update in next rev:
>>>>
>>>> Section will read like this:
>>>>
>>>> ;
>>>> /Knowing the path associated with flows/packets, the end host may/
>>>> /deduce certain characteristics of the path on its own, and/
>>>> /additionally use the information supplied with path information/
>>>> /pushed from the controller or received via pull request. The host/
>>>> /may further share its path observations with the centralized agent,/
>>>> /so that the latter may keep up-to-date network health map to assist/
>>>> /other hosts with this information./
>>>> //
>>>> /For example, an application A.1 at HostA may pin a flow destined/
>>>> /to HostZ via Spine node Node5 using label stack {16005, 16011}. The/
>>>> /application A.1 may collect information on packet loss, deduced from/
>>>> /Other offline mechanisms. [There are some pingMesh mechanisms which /
>>>> /Can be used here]/
>>>> /Through these mechanisms information to a centralized agent, e.g./
>>>> /after a flow completes, or periodically for longer lived flows./
>>>> /Next, using both local and/or global performance data, application/
>>>> /A.1 as well as other applications sharing the same resources in the/
>>>> /DC fabric may pick up the best path for the new flow, or update an/
>>>> /existing path (e.g.: when informed of congestion on an existing/
>>>> /path)./
>>>> ;
>>>>
>>>>>
>>>>>
>>>>>>>
>>>>>>> Section 3, 3rd bullet point:
>>>>>>> It is the foundation of TCP that the network is regarded as a
br/>>>>>>>> black box and that you infer from the transmission of packets
br/>>>>;>>>> what the current state of the network path is. Inferring
network br/>>>>>>>> path metrics (you mention SRTT, MSS, CWND ) is a bad
idea, as br/>>>>>>>>; this would required that all paths exhibit this and
if not what br//>>>>>>>> is going to happen?
>>>>>>> It could be an interesting research field to change many points
br/>>>>>>>> in TCP'ss behavior, but this once again points to the fact that
br/>>>&>>>>> this not the IETF works but IRTF or elsewhere.
>>>>>> [Gaurav] Martin, Authors are trying to suggest that TCP is rightly
br/>>>>>>> treating Network as Black Box. Authors are implying per path
br/>>>>;>>> performance metrics as not cached. Is there some change in text
br/>>>>>>> you are suggesting??
>>>>>
>>>>>
>>>>> I would recommend to remove the 3rd bullet point completey. TCP
br/>>>>>> isn't the place to rememmber "good" or "bad" paths. This is
br/>>>>>> something the network could decide, e.g., rerouting TCP flows
br/>&ggt;>>>> within the network or changing the forwarding path in the
network br/>>>>>> for particular flows (if it is not routed).
>>>>
>>>> <Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd
br/>>>>> bullet point. Willl update in next rev - coming shortly.
>>>>
>>>>>
>>>>> Kind regards,
>>>>>
>>>>>  Martin
>>>>>
>>>>