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

Gaurav Dawra <gdawra.ietf@gmail.com> Mon, 03 September 2018 11:29 UTC

Return-Path: <gdawra.ietf@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80860130E34; Mon, 3 Sep 2018 04:29:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtpQM51Qa0xx; Mon, 3 Sep 2018 04:29:37 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D4A130E32; Mon, 3 Sep 2018 04:29:36 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id x26-v6so193598lfi.7; Mon, 03 Sep 2018 04:29:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x0fgL4vXQI+Gpww2Wase4yM/ShSS1PhPGT06YQM6ceo=; b=iDEHH37UnAUJRVNji3i2cJrFrMkvErm2iiLim7ujwFrmasvGiIcOMKoKcJkkOqg6K4 J7QH2CXhRI8a/sGyPatANGVN33I8eMy4QywI1jh6kbNPvfCzqEA6UZc6M2X5lB7MKAoF RX2M3Ggv4HztNhhlq32FTCd4Qon4OhnkWHRgggXNK2L47NKUONtbGRidFJWZf5rsmdIE oV2hKhIh4ov4JJDUcrZG+7XGidI22ktVPGqRgc3DK3WxAofnYrBCpNouuz952DOcS358 QcNVIvZ5bQ5Dq4qT7lcjGh3JFdIMLVuJ6DOoR171ctHhYn11/JVURSIcYEdg4GjiO/14 jJzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x0fgL4vXQI+Gpww2Wase4yM/ShSS1PhPGT06YQM6ceo=; b=LKLXVDHj2TaZT1d1RVrNxh/qAMSdt8nes1AekYEk6yzR0+YoUcyDmONL2ueLz3LdOP 5j+x+KhJ3IYWhztvWA63A/zQYabLw9gm500+hD3EXFSzJvBC7dYItObdhJSKpZaNhHFl h0i4axi7tsUnmRYKUnvUxr2tnh1998An62j4VSiOHHae3A5wWiVF8v0GH1KeGa2QEevT ixvsnO8SSH5bfG5061o4yi7mUk1M+HqwAKi6jkpsBoB8gPIUp8G2OJxBiHaMWoEZHuFk FhfxCECAG2XTQmUSnS80m8SmuLSa/zyqomoRJAw9BUIDk69pkLczcI70bvHmouvkhpWC 8RRA==
X-Gm-Message-State: APzg51ARxxlGgSODund1t0ykVWvrsDJx5NgEFsYXzMr8eD1IyLuEJa1j bgVwq7cWNrXQKKQ41ath3hXvG83o1CRaEa2nDVA=
X-Google-Smtp-Source: ANB0VdZrxDeccs/l1Oqlvcpabj6ASxd/hhRB80Ru4J8TDyWkKwN+wGMvbc53aOdxptOqXNq7k+mobsiEb9lbQR1MJ7g=
X-Received: by 2002:a19:500f:: with SMTP id e15-v6mr16913240lfb.71.1535974174421; Mon, 03 Sep 2018 04:29:34 -0700 (PDT)
MIME-Version: 1.0
References: <a77a198c-2a5a-d754-8725-6d6685338f6c@gmail.com> <40ED2C86-3403-4D89-8CA8-FBB9651BF2AB@gmail.com> <6dd41180-83bd-c02e-1783-df873e749941@gmail.com> <ACD3CA27-2B92-4BD9-9D2B-A22FE20A65E7@gmail.com> <EC4C550B-05D7-4E6D-A1FD-ED48ECDC3059@gmail.com> <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com> <CAMMESszPMdjpFLjY7aMVaaPbP0GVVZgB_n6hu4gQt6fSbGOi8A@mail.gmail.com> <d0d88a49-9cd8-fad4-9a8f-af45f1a8da2c@gmail.com> <CAMMESsxXhdXGd3k9qzPWqdnLyJb+m50K0y4-U9G=R_E1heoZ-Q@mail.gmail.com> <CAMOQah81UHX0HZM98cyjv50N1hzUqgUi8tUn96HVwPqPvKxW=w@mail.gmail.com> <8652B1BB-C2E7-4324-8E79-E3092362AE1A@gmail.com> <CAMOQah-qL6MxEQKXzEzXN8b3ToSTnX1uJ5AZafh=8E35qv1DZQ@mail.gmail.com> <c4bbf256-9552-ca47-812e-d60838c301c8@kuehlewind.net> <2120B719-EB92-4A47-A26C-0E2E810F1CA8@gmail.com> <CAMOQah9s57vgjUVynBqZim=7fx0745uQeOKARu8DtKdiFU36ng@mail.gmail.com> <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net>
In-Reply-To: <3b257a8a-0455-cd1b-6e95-0e03ab3f1830@kuehlewind.net>
From: Gaurav Dawra <gdawra.ietf@gmail.com>
Date: Mon, 3 Sep 2018 04:29:22 -0700
Message-ID: <CAMOQah9vxzNMqXqKY-YNM1LLBMyryx=bFoDeBp4Da7MCt39Uxg@mail.gmail.com>
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, Martin Stiemerling <mls.ietf@gmail.com>, SPRING WG <spring@ietf.org>, tsv-art@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000cfa830574f5db7f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/GcttmEikQfbn4gEB-_d8jCJu6h4>
Subject: Re: [Tsv-art] [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Sep 2018 11:29:40 -0000

Hi Mirja,

Please see inline...[Gaurav2]

On Thu, Aug 9, 2018 at 8:30 AM Mirja Kühlewind <ietf@kuehlewind.net> wrote:

> Hi Gaurav,
>
> please see inline.
>
> On 03.08.2018 07:20, Gaurav Dawra wrote:
>
> Hey Mirja,
>
> Sorry for the long delay. I was traveling constantly since IETF and bit
> lost in my mailbox and discussion with Authors. Please see my response
> inline[Gaurav]
>
>
> I think with your changes you addressed explicit problems Martin called
> out, however, I still have high level concerns about these sections as they
> are mostly giving speculative recommendation which are not clear to me to
> work in practice.
>
> Regarding section 7.1, you say
> "A flowlet is defined as a burst of packets from the same flow followed by
> an idle interval."
> but then you say
> "...then the application can break the elephant flow F into flowlets F1,
> F2, F3, F4..."
>
> This sounds like you would just divide an elephant flow mostly randomly
> into flowlets which can interact badly with the congestion control. If you
> actually have chunks of data that are transmitted with large enough idle
> interval in between (as you define flowlets in the first sentence), that is
> not an elephant flow anymore and it will not help you to "spread the load
> of the elephant flow through all the ECMP paths". In summary I actually
> don't see how the concept of flowlets can be helpful to address the problem
> you have at all, and I still advise you to remove section 7.1 entirely.
>
> [Gaurav] Hi Mirja, Thanks for the review. The proposal here is no
> different that current ECMP hashing at flowlet level. The only difference
> which is being pointed out here is that if we use SR, we could leverage on
> the ability of be aware of multiple disjoint paths rather than the hashing.
> It’s pins the flowlets to particular paths which is basic SR operations.
>
>
> Yes the problem is that we usually don't recommend ECMP hashing on flowlet
> level because it can interact badly with the end-end mechanisms of that
> flow. As I said, I don't see how the notion of flowlets help you problem
> and therefore I still recommend to remove that paragraph.
> [Gaurav2] OK. It took sometime to get to consensus with authors. Will
> update the text to use 5-tuple flows instead of flowlets. Would that
> suffice? I will update the text shortly.
>
>
> Regarding section 7.2, I also still skeptical about any benefits that can
> be achieved. Given you are in a data center, the controller should already
> know about static parameters such as the maximum bandwidth per link.
>
> For dynamic parameters, e.g. like loss rate, measuring them on a per-flow
> bases is the wrong thing to do. What I mean is you can ask a router about
> the average loss rate that it observes and that might give you some
> valuable, however, if you ask a TCP flow about the average loss rate the
> answer will mainly depend on the congestion controller used and the
> currently available bandwidth, which is a very dynamic property and not a
> link characteristic. So this information is not usable for performance
> aware routing. A flow could give you information about the observed RTT
> (min/max) on a certain path, or the maximum available bandwidth on a path,
> but as I said, given you are in a data center environment these are
> information that the controller already should have anyway.
>
> [Gaurav] They are two separate mechanisms. Most DCs have some sort of
> data-plane/ECMP aware tracing mechanism to detect the loss/delays and can
> be combined with Application back-off to detect issue. All this section is
> suggesting is that SR can be used to pin the path to particular set of ECMP
> paths instead of relying on ECMP hashing.
>
>
> This is not quite what the text says. If that is the statement you want to
> make, that is fine but then you don't need to talk about performance aware
> routing at all.
>
[Gaurav2] I will update the text here with statement i mentioned above.
IMHO, it's performance aware routing wrt to end-host traffic.

>
>
> Your example with detecting a faulty path due to losses does not work with
> TCP as you never know if these loses are due to a problem on the path,
> self-induced or by a competing flow. And even if you don't use TCP and e.g.
> send constant bit rate traffic, there may be a large number of competing
> TCP flows that can induce the loses. Try to steer traffic "away" on a
> time-scale that is slower than TCP dynamics or even your flow dynamic (when
> flows start or end) in case you have a lot of very short flow, in the best
> case doesn't work and in the worst case leads to oscillation.
>
> [Gaurav] As I said above, there are other mechanisms to detect loss and
> trace the path on which loss is seen. This is a common mechanism used in
> MSDCs.
>
> I think this is beyond the scope of the document.
>
[Gaurav2] Will update the text.

>
>
>
> I am happy to discuss further over the phone to try to explain the thought
> process. I will also do check again with Authors to update the text or
> something else based on our conversation.
>
>
> Maybe see if some update can be made to the text first and then we can
> have another discussion if needed.
> [Gaurav2] Sounds good. Will update the text shortly and then we can
> discuss if needed.
>

Cheers,

Gaurav

>
>
> Cheers,
>
>
>
> Gaurav
>
> If you want to make TCP use for handover situation where one path might go
> away or become unusable, it's best to use Multipath TCP (with coupled
> congestion control) instead because that works on the right time scale.
> Again, I don't think this is a use case for SR and I would recommend to
> remove the section entirely.
>
> Mirja
>
>
>
>
> On Mon, Jul 16, 2018 at 11:08 PM, Gaurav Dawra <gdawra.ietf@gmail.com>
> wrote:
>
>> Hi Mirja,
>>
>> Ack. Let me work with authors to close ASAP.
>>
>> Cheers,
>>
>> Gaurav
>>
>> Sent from my iPhone
>>
>> On Jul 5, 2018, at 10:06 AM, Mirja Kühlewind <ietf@kuehlewind.net> wrote:
>>
>> Hi Gaurav,
>>
>> sorry for my very long delay but this got somehow a bit lost in my
>> mailbox.
>>
>> I think with your changes you addressed explicit problems Martin called
>> out, however, I still have high level concerns about these sections as they
>> are mostly giving speculative recommendation which are not clear to me to
>> work in practice.
>>
>> Regarding section 7.1, you say
>> "A flowlet is defined as a burst of packets from the same flow followed
>> by an idle interval."
>> but then you say
>> "...then the application can break the elephant flow F into flowlets F1,
>> F2, F3, F4..."
>>
>> This sounds like you would just divide an elephant flow mostly randomly
>> into flowlets which can interact badly with the congestion control. If you
>> actually have chunks of data that are transmitted with large enough idle
>> interval in between (as you define flowlets in the first sentence), that is
>> not an elephant flow anymore and it will not help you to "spread the load
>> of the elephant flow through all the ECMP paths". In summary I actually
>> don't see how the concept of flowlets can be helpful to address the problem
>> you have at all, and I still advise you to remove section 7.1 entirely.
>>
>> Regarding section 7.2, I also still skeptical about any benefits that can
>> be achieved. Given you are in a data center, the controller should already
>> know about static parameters such as the maximum bandwidth per link. For
>> dynamic parameters, e.g. like loss rate, measuring them on a per-flow bases
>> is the wrong thing to do. What I mean is you can ask a router about the
>> average loss rate that it observes and that might give you some valuable,
>> however, if you ask a TCP flow about the average loss rate the answer will
>> mainly depend on the congestion controller used and the currently available
>> bandwidth, which is a very dynamic property and not a link characteristic.
>> So this information is not usable for performance aware routing. A flow
>> could give you information about the observed RTT (min/max) on a certain
>> path, or the maximum available bandwidth on a path, but as I said, given
>> you are in a data center environment these are information that the
>> controller already should have anyway.
>>
>> Your example with detecting a faulty path due to losses does not work
>> with TCP as you never know if these loses are due to a problem on the path,
>> self-induced or by a competing flow. And even if you don't use TCP and e.g.
>> send constant bit rate traffic, there may be a large number of competing
>> TCP flows that can induce the loses. Try to steer traffic "away" on a
>> time-scale that is slower than TCP dynamics or even your flow dynamic (when
>> flows start or end) in case you have a lot of very short flow, in the best
>> case doesn't work and in the worst case leads to oscillation.
>>
>> If you want to make TCP use for handover situation where one path might
>> go away or become unusable, it's best to use Multipath TCP (with coupled
>> congestion control) instead because that works on the right time scale.
>> Again, I don't think this is a use case for SR and I would recommend to
>> remove the section entirely.
>>
>> Mirja
>>
>>
>> On 05.07.2018 04:08, Gaurav Dawra wrote:
>>
>> Hey Alvaro, Mirja,
>>
>> Friendly reminder to further progress this document.
>>
>> Cheers,
>>
>> Gaurav
>>
>> On Mon, Jun 18, 2018 at 5:13 PM, Gaurav Dawra <gdawra.ietf@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.ietf@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.ietf@gmail.com>
>>> wrote:
>>>
>>>> Thanks Martin!
>>>>
>>>> On June 6, 2018 at 3:14:45 PM, Martin Stiemerling (mls.ietf@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.ietf@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.ietf@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.ietf@gmail.com
>>>> br/>>>> <mailto:gdawra.ietf@@gmail..com <http://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.ietf@gmail.com br/>>>>>> <mailto:mls.iietf@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.ietf@gmail.com> br/>>>>>>>>; <mailto:
>>>> mls.ietf@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/>>>&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
>>>> >>>>>
>>>> >>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Tsv-art mailing listTsv-art@ietf.orghttps://www.ietf.org/mailman/listinfo/tsv-art
>>
>>
>>
>
>