RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

Lin Han <Lin.Han@huawei.com> Sat, 21 October 2017 01:15 UTC

Return-Path: <Lin.Han@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FFF126B7E for <ipv6@ietfa.amsl.com>; Fri, 20 Oct 2017 18:15:01 -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, 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 pQ27rDtzP2iS for <ipv6@ietfa.amsl.com>; Fri, 20 Oct 2017 18:15:00 -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 D3579124B17 for <ipv6@ietf.org>; Fri, 20 Oct 2017 18:14:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRB03720; Sat, 21 Oct 2017 01:14:58 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 21 Oct 2017 02:14:57 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML703-CHM.china.huawei.com ([169.254.5.27]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 18:14:47 -0700
From: Lin Han <Lin.Han@huawei.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
CC: 6man WG <ipv6@ietf.org>
Subject: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]
Thread-Topic: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]
Thread-Index: AQHTSdJXqSaZrOZDMkmbu8uyH2nDS6LtjQWA//++ciCAAKNsAP//jLNQ
Date: Sat, 21 Oct 2017 01:14:47 +0000
Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD76B4E@sjceml521-mbx.china.huawei.com>
References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <cc11634a-b5a2-88b9-f36f-82b3fd9d8d70@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <a4da4b26-6402-ad0d-a5f5-5bddc192b8f7@gmail.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org> <CALx6S341v1zd2Q9bts8-zrKxU59kieJTJJ=nHQ5w4oQZg=t_cA@mail.gmail.com> <17525287-DDA8-4930-B90B-F9228DF69A90@employees.org> <CALx6S37wLvuJ9tUGjYmzm63eq_bxq0jXSEgfCtH_2i74SvrbLA@mail.gmail.com> <20171017181646.GD31973@faui40p.informatik.uni-erlangen.de> <e7da5913-1fd9-a476-e654-44cb5cfdc10c@gmail.com> <20171019212353.GC878@faui40p.informatik.uni-erlangen.de> <e4f7ea8b-ce0e-d829-7b1e-b53c3a890355@gmail.com> <e03ad50248824701bf3f6fbedcfa1ca4@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD768D2@sjceml521-mbx.china.huawei.com> <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.com> <1D30AF33624CDD4A99E8C395069A2A162CD76A38@sjceml521-mbx.china.huawei.com> <5dc02378-28ff-e55a-6034-3faae396402f@gmail.com>
In-Reply-To: <5dc02378-28ff-e55a-6034-3faae396402f@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.49.91]
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.0A020206.59EA9F92.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.102, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 0a9594e3c0fa60c315aeab1c5e2f11ae
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/j0IOb_IRNBmW3A5gowhSYlsJqWE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Oct 2017 01:15:02 -0000

>Keep your average network utilisation well below 10% and your QoS problems are solved.
>It's just queueing theory.

Kind of correct. If all links are never congested, there is no problem and requirement for QoS especially for bandwidth. But this is not practical for SP. In reality, there are always oversubscription at network aggregation device, such as TOR, PGW, BRASS, etc. Thus the congestion will never go away. Most of applications don’t feel pain if it is not bandwidth/latency sensitive, but for some applications, this may not be true anymore.
For latency requirement, it is not gone even the network load is below link capacity, so, the QoS is still required. 


Lin


-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
Sent: Friday, October 20, 2017 5:51 PM
To: Lin Han <Lin.Han@huawei.com>; Manfredi, Albert E <albert.e.manfredi@boeing.com>
Cc: 6man WG <ipv6@ietf.org>
Subject: Re: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

On 21/10/2017 12:27, Lin Han wrote:
...
> On the other hand, also in these controlled environments, another option, frequently, is to "throw bandwidth at the problem." Give yourself plenty of headroom. It's less elegant and less fun, but it works great.
> [LH] not completely get what you mean 

Keep your average network utilisation well below 10% and your QoS problems are solved.
It's just queueing theory.

   Brian