[DLNEX] passive probe measuring network latency in combination of network exposing Latency for special services

Linda Dunbar <linda.dunbar@huawei.com> Wed, 19 October 2016 16:49 UTC

Return-Path: <linda.dunbar@huawei.com>
X-Original-To: dlnex@ietfa.amsl.com
Delivered-To: dlnex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A060512967D; Wed, 19 Oct 2016 09:49:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.651
X-Spam-Level:
X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 IZaglTE2F3Ns; Wed, 19 Oct 2016 09:49:41 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C9BB12951D; Wed, 19 Oct 2016 09:49:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYN93414; Wed, 19 Oct 2016 16:49:37 +0000 (GMT)
Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 19 Oct 2016 17:49:36 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Wed, 19 Oct 2016 09:49:30 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "dlnex@ietf.org" <dlnex@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: passive probe measuring network latency in combination of network exposing Latency for special services
Thread-Index: AdIqJktwDPj+dhwvS7KEnfB6wzP2DA==
Date: Wed, 19 Oct 2016 16:49:29 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F5D06E@dfweml501-mbb>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.156.160]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F5D06Edfweml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5807A422.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a757845e09f4ce6102b4afd85a42d980
Archived-At: <https://mailarchive.ietf.org/arch/msg/dlnex/OjTi24JKOM-XHQL6TMCrTuVU91g>
Subject: [DLNEX] passive probe measuring network latency in combination of network exposing Latency for special services
X-BeenThere: dlnex@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Discussion of reliable and deterministic latency attributes <dlnex@ietf.org>
List-Id: Discussion of reliable and deterministic latency attributes <dlnex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dlnex>, <mailto:dlnex-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dlnex/>
List-Post: <mailto:dlnex@ietf.org>
List-Help: <mailto:dlnex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dlnex>, <mailto:dlnex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2016 16:49:45 -0000

At NANOG this week, there are many companies showing off their network monitoring capability, from BGP route monitoring to Latency Monitoring. Companies like Teridion, ThousandEyes, Internap, etc. all use passive probe packets to measure the latency through a network. Some of those companies can provide shorter latency path for upper layer.

If network elements or segments support DETNET, OIF's FlexEthernet, or other latency optimized mechanisms within a node, and can allocate resource for a percentage of traffic (latency sensitive flows), is it is more valuable for those nodes or segments to expose the upper bound latency to upper layers on those flows than the passive monitoring with probes? Possible for upper layer to request those resources (via some kind of control plane)? Like what CCAMP has done?

Facebook presentation at NANOG pointed out (https://www.nanog.org/sites/default/files/20160922_Quinn_Being_Open_How_v1.pdf ):
BGP can only do so much
* BGP offers little data about the forwarding plane
* BGP "best" paths are oblivious to:
* Capacity
* Latency
* Packet Loss
What if the network elements can expose those attributes?

Just some points for discussion.

Linda Dunbar