Re: [Idnet] Network AI Use case: Predicting-based QoS ensurance

Sheng Jiang <jiangsheng@huawei.com> Thu, 29 June 2017 01:49 UTC

Return-Path: <jiangsheng@huawei.com>
X-Original-To: idnet@ietfa.amsl.com
Delivered-To: idnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0598129B13 for <idnet@ietfa.amsl.com>; Wed, 28 Jun 2017 18:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NIjfVcjtnhCH for <idnet@ietfa.amsl.com>; Wed, 28 Jun 2017 18:49:15 -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 7E0A1127F0E for <idnet@ietf.org>; Wed, 28 Jun 2017 18:49:14 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJJ39870; Thu, 29 Jun 2017 01:49:12 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 29 Jun 2017 02:49:10 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 29 Jun 2017 09:48:52 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: yanshen <yanshen@huawei.com>, "idnet@ietf.org" <idnet@ietf.org>
Thread-Topic: Network AI Use case: Predicting-based QoS ensurance
Thread-Index: AdLvPDXrGZ4x6ryKT+muuTFXqIbX5gBNU8lg
Date: Thu, 29 Jun 2017 01:48:52 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDF2256@NKGEML515-MBX.china.huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D295F821@DGGEMM505-MBX.china.huawei.com>
In-Reply-To: <6AE399511121AB42A34ACEF7BF25B4D295F821@DGGEMM505-MBX.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.185.119]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59545C98.0084, 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: 2936f0814e6cfdeaa1d9e5ea5595da69
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/j498LpCUE-2xbQsLKs3i7jMVnmA>
Subject: Re: [Idnet] Network AI Use case: Predicting-based QoS ensurance
X-BeenThere: idnet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The IDNet \(Intelligence-Defined Network\) " <idnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idnet>, <mailto:idnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idnet/>
List-Post: <mailto:idnet@ietf.org>
List-Help: <mailto:idnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idnet>, <mailto:idnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jun 2017 01:49:17 -0000

Hi, Yanshen,

Thanks for the use case. This use case by itself is useful and attractive. I also agree the two challenge you like are something that is worth working on. However, this use case is based on the precondition of accurate traffic prediction. As far as we know, there are many existing efforts on the prediction for the traffic changes. However, for my understanding, although most of existing efforts does not have the ability to do traffic prediction, there are many limitations. I don't think the current result of traffic prediction could be mature enough to support your use case. So far, the traffic prediction can only have good result on certain conditions, such as on limited interface or devices, for certain type of traffic models. 

So far, there are at least three aspects that the traffic prediction needs to be largely improved: a) granularity b) error range or accurate c) calculation time assumption d) universal validity, independent from certain topology or certain traffic model, including prediction on small traffics, reduce the influence of traffic burst, etc.

Regards,

Sheng

> -----Original Message-----
> From: yanshen
> Sent: Tuesday, June 27, 2017 7:59 PM
> To: idnet@ietf.org
> Subject: Network AI Use case: Predicting-based QoS ensurance
> 
> Hi all,
> 
> I try to list some valuable use cases that the AI technology may play a role in
> the network management and optimization.
> 
> Use case 01: Use prediction to ensure VPN's QoS
> 
> It is worthy to predict the traffic change for avoiding the congestion and
> ensuring QoS. As the following figure shown, the AI system continuously
> collects link status data from the network. This AI system is responsible for two
> things. One is monitoring and predicting the traffic on each link and the other
> one is calculating the usable route for any pair of nodes according to the
> prediction and current link status. Assume that there is a VPN named VPN_S_D
> from node S to D which pass through S-A-B-C-D. According to the prediction,
> there will be a huge traffic flow from node A to C in the future 10 min. The
> traffic will increase the end-to-end delay from S to D so that the QoS will not be
> ensured.
> 
>                 \/     \/
>                 /\     /\			 ----->
>            _ A ----- B ----- C._      link status data       -----------
>          ,'     \      /     `.   =================| AI system |
>        -'        \    /          `-                    -----------
>      S ----------I------ J -------K -------  D
>        .         /    \          ,'
>         `.      /       \      ,'
>           '  O ---- P ----  Q '
> 
> There are at least two solutions. one is modifying the object's configuration to
> avoid the potential congestion. For example, we modify the VPN_S_D's route
> from S-A-B-C-D to S-I-J-K-D. The other one is restricting non-object's
> transmission so that to protect the object's QoS. For example, we increase the
> reserved bandwidth of VPN_S_D or modify the route of non-object flows from
> S-A-B-C-D to S-I-J-K-D therefore most of the traffic will not affect VPN_S_D.
> 
> Here we may have some challenges.
> 
> Challenge 1 is the AI prediction and autonomic decision should be a quick
> response. The whole process must be finished before the congestion happens
> meanwhile the AI system is meaningless. The question is how to implement
> such quick response?
> 
> Challenge 2 is whether there is existing protocols which can support high
> frequency measurement? Because AI system needs to be fed with continuous
> link status data. And the real-time data need to be captured frequently
> otherwise the route change will be worthless. I think the protocols that support
> high frequency measurement and data collection may become one of our
> focuses.
> 
> regards,
> 
> 
> ------------------------------------------------------------------------------------------
> Yansen