Re: [Detnet] Traffic description in DetNet flow info model

zhayiyong <zhayiyong@huawei.com> Fri, 21 April 2017 07:37 UTC

Return-Path: <zhayiyong@huawei.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A6112947C for <detnet@ietfa.amsl.com>; Fri, 21 Apr 2017 00:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level:
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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.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 hloA4sXaY5iQ for <detnet@ietfa.amsl.com>; Fri, 21 Apr 2017 00:37:51 -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 B2114127843 for <detnet@ietf.org>; Fri, 21 Apr 2017 00:37:50 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFG06366; Fri, 21 Apr 2017 07:37:48 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 21 Apr 2017 08:37:43 +0100
Received: from DGGEMM508-MBS.china.huawei.com ([169.254.4.204]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Fri, 21 Apr 2017 15:37:36 +0800
From: zhayiyong <zhayiyong@huawei.com>
To: John Grant <j@ninetiles.com>, DetNet WG <detnet@ietf.org>
Thread-Topic: [Detnet] Traffic description in DetNet flow info model
Thread-Index: AdK5qSSYqSHwGD/BTl6GOqTnuhSZH///mCAA//4S91A=
Date: Fri, 21 Apr 2017 07:37:36 +0000
Message-ID: <E78F7186ADD5404AB48E27F02660CA07806C9D61@dggemm508-mbs.china.huawei.com>
References: <E78F7186ADD5404AB48E27F02660CA07806C9BDC@dggemm508-mbs.china.huawei.com> <3B18D368-5822-4007-88F8-A02C875D7BAE@ninetiles.com>
In-Reply-To: <3B18D368-5822-4007-88F8-A02C875D7BAE@ninetiles.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.15.96]
Content-Type: multipart/related; boundary="_006_E78F7186ADD5404AB48E27F02660CA07806C9D61dggemm508mbschi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58F9B6CD.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.204, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4c86b19d51d7e2bc0fbcd75c8a5f626e
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/qq86SfUeX9SvN4hgi3IwUX-k9Iw>
Subject: Re: [Detnet] Traffic description in DetNet flow info model
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 07:37:55 -0000

Hi John,

Thank you for the reply. I agree that make reservation on peak rate is a simple solution. But the "peak rate" here depends on the observation interval times max packets per interval, which means for same flow, different interval leads to different peak rate. Below is a little testbed we built to test the burstness feature of TCP flow.
For the same 25Mbps TCP flow with no shaping:

[cid:image007.jpg@01D2BAB5.335C2750]
1s observation interval, peak rate 450Mbps.

[cid:image008.jpg@01D2BAB5.335C2750]
100ms observation interval, peak rate 900Mbps.

[cid:image009.jpg@01D2BAB5.335C2750]
10ms observation interval, peak rate 1Gbps, which is the link speed/physical port speed.

And further test shows that, 8 of these TCP flows to a 1Gbps port cause packet loss. So my question is how can we make reservation based on "peak rate"? E.g., for the same flow, if we take 1s observation interval, we can serve 2 flows. But for 10ms observation interval, only 1 flow, which does not make sense. And it is hard to say long observation interval can guarantee delay and loss, since buffer in router is only milliseconds level.

Another thing is how to guarantee the source with max packets within the interval. If shaping is necessary, what kind of parameters are needed.

Cheers,
Yiyong
From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Grant
Sent: Thursday, April 20, 2017 5:27 PM
To: DetNet WG
Subject: Re: [Detnet] Traffic description in DetNet flow info model

As pointed out in 4.1.2, for a VBR flow you have to make a reservation for the peak rate, and there isn't any reason to do anything other than use the service that is already defined for CBR. With circuit-switched systems any part of the reservation that wasn't used was wasted, but in packet-based systems it can be used for best-effort traffic, as stated in 4.3.2.

Regarding synchronous flows, the first paragraph of 4.3.2 explains that if the reservations on incoming and outgoing links are time-aligned then the latency, and hence the amount of buffer space required, can be minimised. The details mechanism for achieving that would, I think, be out of scope for an architecture document.

For a description of a system that implements synchronous flows, see clause 5 of ETSI GR NGP 003, available from the "specifications" tab at http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols

John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com
On 20 Apr 2017, at 08:38, zhayiyong wrote:


Hi All,

Recently we have some discussion among authors of the two flow info model draft. The DetNet flow info model should provide some common concepts and description of the flow. One part is traffic specification of the flow. Here is something not clear, is DetNet dealing with VBR flows and what attributes are needed? And how to deal with VBR flow, for source guarantee purpose, do we need to define shaping parameters?

In architecture draft, section 4.1.2, "The traffic characteristics of an App-flow can be CBR (constant bit rate) or VBR (variable bit rate)". In section 4.3.2, mentions synchronous flow and asynchronous flow, but no details of that.
In use case draft, for some cases such as industrial and BAS, it can assumes that the traffic is periodic with constant rate. For cases such as Cellular Radio and M2M, there is usually no assumption on the traffic. E.g., CoMP traffic is between two eNBs, it is hard to say the flow is constant rate.

Cheers,
Yiyong
_______________________________________________
detnet mailing list
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet