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

Alvaro Retana <aretana.ietf@gmail.com> Wed, 30 May 2018 19:55 UTC

Return-Path: <aretana.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 8592412EAED; Wed, 30 May 2018 12:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 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_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 5rwpfDKb78nT; Wed, 30 May 2018 12:55:37 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 9623E12E87D; Wed, 30 May 2018 12:55:37 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id i205-v6so2896486oib.1; Wed, 30 May 2018 12:55:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=7YwhHjlOiEl3L4TDKsM3M75aizvnwHz9mzN4X8c039g=; b=M3mafabOoEAPon6mbtPtsq8IYWuGJBLMW6EgDw8vKa9XGcBaM9TxN8FTlyeFxgcjp9 oTHWvAzu5wpOGIAysgnO529plpL5CSF7kkevGkQm1hlox30tmSWYqGzxQifU0r1ZZJ0o 1ogQcPaOOX8ajwdmvBRl8d4glOktmpYvIOBX4Fx/viJXFUu9dezAaUs+cXL24NcBSoB1 uKLx6uDDNLQgps3aYsQo8cszK8s9LNJHeU5OvA1MKGi0TI0STgfaq8f98Dh4LcolREj9 LCaABJMt0hsItfnsAtkL+jqMxsRRAW5Ae07SaEFrvi7xAr9cFVi+hyUPNEmH7u130FNS px/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=7YwhHjlOiEl3L4TDKsM3M75aizvnwHz9mzN4X8c039g=; b=S29Ejen31Jumllx3Ln0k1tKb/d3f5CqHj0MHWEapD9ojPr8SkrFvPM1yGTTAneW1ZX UYRZnxhN6XXb3bRBDhhM/7RSZCK4RlKgq61b7z23LAWhQyxnhtoyeqRDyfwEfzNgT85I b+dm3hC7H50m0ZZY6nKC7IEuaDMCSGkokOtvMXomB21Yabbg7bJCOeDXinbC4VZcq1EN 7q46QhlRaLwpH2FvEExLwCazGxtRl2SQWk9KBHtYBDj18ZnaNW4tPBwQ02rSVZtDPzaW /6S7dgqEnJ5pwuOZw7zrN1WaU5aQv+OsPoOGFPEKwCP+iIhnqeRHrgz515LE8o6Dec00 9Fvw==
X-Gm-Message-State: ALKqPwdDBNoTQokyuedodTn632hi7JoDGq4rpigCtY+olUN4AO/bXqSU 7DhD7MFU1XP95LlG+mO7lA1OQ5TtcuVRSjqJIrE=
X-Google-Smtp-Source: ADUXVKJMq/K1BjgD72zZY714lA2D25rC49PsGeJ2rkwervWTRK1OyWiGO3Ujh10YbDBRQB4Yg4qDYzKLuydkQaKlq9U=
X-Received: by 2002:aca:4707:: with SMTP id u7-v6mr2403135oia.229.1527710136977; Wed, 30 May 2018 12:55:36 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 30 May 2018 15:55:36 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <465981C7-7AB1-43AF-8A80-69D835871077@gmail.com>
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>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Wed, 30 May 2018 15:55:36 -0400
Message-ID: <CAMMESszPMdjpFLjY7aMVaaPbP0GVVZgB_n6hu4gQt6fSbGOi8A@mail.gmail.com>
To: Martin Stiemerling <mls.ietf@gmail.com>
Cc: tsv-art@ietf.org, spring@ietf.org, Gaurav Dawra <gdawra.ietf@gmail.com>, Mirja Kühlewind <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="00000000000008cea8056d71bcbc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/nyhElCz5P_5WKpVXQ_gPt4WGVfE>
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.22
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: Wed, 30 May 2018 19:55:48 -0000

Martin:

Hi!  How are you?

Gaurav just posted a revision.  Please take a look and let us know if the
changes address your concerns or not.

https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-msdc-09

Thanks!!

Alvaro.

On May 25, 2018 at 12:08:46 PM, Gaurav Dawra (gdawra.ietf@gmail.com) wrote:

Hi Martin,

Thanks for review. I will post the new version. Hopefully, it will address
all your comments and we can close this 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> wrote:

Hi Martin,

Thanks for the review. Any further comments here ? I will post the new
version soon.

Cheers,

Gaurav

Sent from my iPhone

On May 16, 2018, at 7:44 PM, Gaurav Dawra <gdawra.ietf@gmail.com> wrote:

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 <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