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

[Gaurav Dawra <[e-mail]>]

Hey Alvaro, Mirja,

Friendly reminder to further progress this document.

Cheers,

Gaurav

On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra <[e-mail]> wrote:

> Hi Alvaro, Mirja
>
> Any feedback or next steps to close this?
>
> Cheers,
>
> Gaurav
>
> Sent from my iPhone
>
> On Jun 12, 2018, at 7:06 AM, Gaurav Dawra <[e-mail]> wrote:
>
> Hi Mirja,
>
> Friendly Reminder...Could you please also advice if there is anything
> further to DISCUSS on this document which was also related to TCP updates
> below?
>
> Cheers,
>
> Gaurav
>
> On Thu, Jun 7, 2018 at 9:02 AM, Alvaro Retana <[e-mail]>
> wrote:
>
>> 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/d
>> raftt-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
>> >>>>>
>> >>>>
>>
>>
>