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

Gaurav Dawra <gdawra.ietf@gmail.com> Thu, 17 May 2018 02:44 UTC

Return-Path: <gdawra.ietf@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A112312711B; Wed, 16 May 2018 19:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, URIBL_BLOCKED=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 f8KVYcbpwVdg; Wed, 16 May 2018 19:44:38 -0700 (PDT)
Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (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 D405F126C26; Wed, 16 May 2018 19:44:37 -0700 (PDT)
Received: by mail-pl0-x233.google.com with SMTP id c19-v6so1572463pls.6; Wed, 16 May 2018 19:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WRgz0UcNvcolBvRyGBwyHpa9/EQWvQ2WxBV3ozO4ELU=; b=Z9xTAgm5vv+4lMR288rPiiFPCaQGK/pKaweerXDWL1gNqh21IKMzGHTcVyYw8xkUY5 SFBRAyXa+ByhCfCZBcLoP4tHrkTK5UHCyIGzvJXtILb730aVPC42pxKAe9YU2QR9Vq/y hwhOE9Yd7nEb+LQ9z+gn/4OyYpaStQXVZFGgi7TCtOBhtiHgIIk/W/w9wP8c4qBjGoh0 zMgghFbW618bOjovqNvfDIzhkFQK1/Wt3rWR+HK+l3XXnBwZtpoIr973GuT6LdZrckMz Q1sK9nKL/lenggLKRa/OBxMQ7dnaIDNpG50rLollfR6kUVRhE0kpB1ulLlGgp0poczbm kOrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WRgz0UcNvcolBvRyGBwyHpa9/EQWvQ2WxBV3ozO4ELU=; b=g/s8bsPbONUTKbkYMvUdI4yCZzsiYdkCEpijHKDwihiMQ62hl5XvPpXiablk6mpOMf 5cilVq+EAeJRNMkGId3MRvpfmyn+xcuFRvIUw2VtJmt+BtfXSDuj8VbUcJhOIU8iHNMR ICAIYYwjQAPIHoncq4UJvMccN6OSfnNKfL0SBabthS3dyIGR3TQ8uOQjP7El48rVRwMF D2074hQizLZJv3dmphaanxCQwtRXXhcQnl90DZADxnPJtrQOCO6oEs5OIz/i06EK+Qwc RRVc388ZQjdAwgE3EXHZOQn4wuKyM2ZWaMuMsHrEesdqx4hNwVekLk8HCYqzZwnsizvZ 7pWg==
X-Gm-Message-State: ALKqPwdC6/xdOwC2dWrjCPF7+cghlS+gDU90+LTHpm6LwCNxGtmSu9mD vE54iQRDpNRFZXqfzIoGXcsdlNga
X-Google-Smtp-Source: AB8JxZqYjcStTTHcB0RT0pOA5NYIQaj6i6q7/WcppOKHJETddhf9nlx08Hzgu4jGgmyBunZuVUoM1g==
X-Received: by 2002:a17:902:a717:: with SMTP id w23-v6mr3398339plq.130.1526525077437; Wed, 16 May 2018 19:44:37 -0700 (PDT)
Received: from ?IPv6:2601:646:9300:3021:b84c:ef7d:31d4:569e? ([2601:646:9300:3021:b84c:ef7d:31d4:569e]) by smtp.gmail.com with ESMTPSA id t68-v6sm6292540pfe.17.2018.05.16.19.44.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 19:44:36 -0700 (PDT)
From: Gaurav Dawra <gdawra.ietf@gmail.com>
Message-Id: <ACD3CA27-2B92-4BD9-9D2B-A22FE20A65E7@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E5B1CE7B-CD2A-4A43-AB29-F697C6141D8D"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 16 May 2018 19:44:36 -0700
In-Reply-To: <6dd41180-83bd-c02e-1783-df873e749941@gmail.com>
Cc: spring@ietf.org, tsv-art@ietf.org
To: Martin Stiemerling <mls.ietf@gmail.com>
References: <a77a198c-2a5a-d754-8725-6d6685338f6c@gmail.com> <40ED2C86-3403-4D89-8CA8-FBB9651BF2AB@gmail.com> <6dd41180-83bd-c02e-1783-df873e749941@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/_e4FU7It_y1o80_HmOiy7EaggI0>
Subject: Re: [spring] TSV-ART review of draft-ietf-spring-segment-routing-msdc-08
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 May 2018 02:44:41 -0000

Hi Martin,

Apologies from my end we had few internal authors conversations on the points you have raised.

Please find below my response. I will be happy to discuss further, if needed.

<Gaurav> inline...

> On Apr 9, 2018, at 7:58 AM, Martin Stiemerling <mls.ietf@gmail.com> wrote:
> 
> 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:
>> Hey Martin,
>> Sorry for late reply. Please see some comments inline[Gaurav]
>>> On Jan 9, 2018, at 2:25 PM, Martin Stiemerling <mls.ietf@gmail.com <mailto:mls.ietf@gmail.com>> 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.
> 
> 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 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-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.
<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 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?
> 
> 
> 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).

<Gaurav> Ack, after discussion, we will remove the Section 3 - 3rd bullet point. Will update in next rev - coming shortly.

> 
> Kind regards,
> 
>  Martin
>