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

yanshen <yanshen@huawei.com> Thu, 29 June 2017 13:14 UTC

Return-Path: <yanshen@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 2FC0E12EC2C for <idnet@ietfa.amsl.com>; Thu, 29 Jun 2017 06:14:33 -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 YyS85pDRnicP for <idnet@ietfa.amsl.com>; Thu, 29 Jun 2017 06:14:31 -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 02B811277BB for <idnet@ietf.org>; Thu, 29 Jun 2017 06:14:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DQB08925; Thu, 29 Jun 2017 13:14:29 +0000 (GMT)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 29 Jun 2017 14:14:28 +0100
Received: from DGGEMM505-MBX.china.huawei.com ([169.254.1.152]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Thu, 29 Jun 2017 21:13:55 +0800
From: yanshen <yanshen@huawei.com>
To: Sheng Jiang <jiangsheng@huawei.com>, "idnet@ietf.org" <idnet@ietf.org>
Thread-Topic: Network AI Use case: Predicting-based QoS ensurance
Thread-Index: AdLvPDXrGZ4x6ryKT+muuTFXqIbX5gBNU8lgABfcjhA=
Date: Thu, 29 Jun 2017 13:13:54 +0000
Message-ID: <6AE399511121AB42A34ACEF7BF25B4D2960023@DGGEMM505-MBX.china.huawei.com>
References: <6AE399511121AB42A34ACEF7BF25B4D295F821@DGGEMM505-MBX.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B927CDF2256@NKGEML515-MBX.china.huawei.com>
In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927CDF2256@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.179.89]
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.0A020202.5954FD35.0115, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.152, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 6728140ec33fd37a09e3bed60d354568
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/475NXT9wCZk9XGPFZbck3WU7100>
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 13:14:33 -0000

Hi Sheng,

Thanks for your response. 

I think there is a question that should be considered. What can be predicted and what cannot? Take the traffic as example. It can be divided into two parts. On one hand, there should be something certain that roughly generate predictable result. One the other hand, there must be something uncertain that unpredictable (such as physical link failure or the burst caused by hidden reasons). For the predictable part, we can use AI method (e.g. Neural Network) to module the traffic according to the statistics. For the unpredictable part, I think it is meaningless to concern because these have been beyond the scope that network and AI technology can cover. IT IS HARD TO SOLVE A HIGHER DIMENSION PROBLEM BY LOWER DIMENSION METHOD. In other word, these type of unpredictable problem should be solve by some other method but AI can join in the process, for example, to launch the backup strategies. Is it reasonable?

The granularity should depend on the specific scenario. For example, if I focus on the quality of some route, the prediction should be based on the interface level. If I focus on the security, such as we use the traffic to judge whether there is data leak, the granularity should be based on the whole scope in focus.

BTW, you give a hint that may become the next high value use case. Thank you very much.

Yansen


> -----Original Message-----
> From: Sheng Jiang
> Sent: Thursday, June 29, 2017 9:49 AM
> To: yanshen <yanshen@huawei.com>om>; idnet@ietf.org
> Subject: RE: Network AI Use case: Predicting-based QoS ensurance
> 
> 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