Hey Alvaro, Mirja, Friendly reminder to further progress this document.
Cheers, Gaurav On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra <gdawra.i...@gmail.com> 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 <gdawra.i...@gmail.com> 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 <aretana.i...@gmail.com> > wrote: > >> Thanks Martin! >> >> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.i...@gmail.com) >> 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 (( >> gdawra.i...@gmail.com 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 <gdawra.i...@gmail.com >> 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 <gdawra.i...@gmail.com >> 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 <mls.i...@gmail.com >> br/>>>>>> <mailto:mls.ii...@gmail.com>> 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:mls.i...@gmail.com> br/>>>>>>>>; <mailto: >> mls.i...@gmail.com>> 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/>>>>t;>>>> 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/>>>>>>>t;> like the Path Aware Networking Proposed >> Research Group br/>>t;>>>>>> (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/>>t;>>>>>> 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/>>>t;>>>> 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 >> >>>>> >> >>>> >> >> >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
