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

yanshen <yanshen@huawei.com> Tue, 27 June 2017 11:58 UTC

Return-Path: <yanshen@huawei.com>
X-Original-To: idnet@ietfa.amsl.com
Delivered-To: idnet@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 221DB129AD1 for <idnet@ietfa.amsl.com>; Tue, 27 Jun 2017 04:58:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Status: No, score=-4.222 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] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7dNV2ikbkKdz for <idnet@ietfa.amsl.com>; Tue, 27 Jun 2017 04:58:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0499F120227 for <idnet@ietf.org>; Tue, 27 Jun 2017 04:58:45 -0700 (PDT)
Received: from (EHLO lhreml706-cah.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX43163; Tue, 27 Jun 2017 11:58:44 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com ( by lhreml706-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 12:58:43 +0100
Received: from DGGEMM505-MBX.china.huawei.com ([]) by DGGEMM406-HUB.china.huawei.com ([]) with mapi id 14.03.0301.000; Tue, 27 Jun 2017 19:58:34 +0800
From: yanshen <yanshen@huawei.com>
To: "idnet@ietf.org" <idnet@ietf.org>
Thread-Topic: Network AI Use case: Predicting-based QoS ensurance
Thread-Index: AdLvPDXrGZ4x6ryKT+muuTFXqIbX5g==
Date: Tue, 27 Jun 2017 11:58:33 +0000
Message-ID: <6AE399511121AB42A34ACEF7BF25B4D295F821@DGGEMM505-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
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.59524874.00B6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e0fb8db4fa27828568dbd327015c9ca5
Archived-At: <https://mailarchive.ietf.org/arch/msg/idnet/jr8SGzcahSDXtj04lc0TSk4kB60>
Subject: [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: Tue, 27 Jun 2017 11:58:48 -0000

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.