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

Lin Han <Lin.Han@huawei.com> Fri, 20 October 2017 23:27 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 4916C13430F for <ipv6@ietfa.amsl.com>; Fri, 20 Oct 2017 16:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 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, 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 C3qLU57n5vkA for <ipv6@ietfa.amsl.com>; Fri, 20 Oct 2017 16:27:49 -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 2F718132A1A for <ipv6@ietf.org>; Fri, 20 Oct 2017 16:27:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYD97122; Fri, 20 Oct 2017 23:27:47 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 21 Oct 2017 00:27:46 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.102]) by SJCEML702-CHM.china.huawei.com ([169.254.4.145]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 16:27:42 -0700
From: Lin Han <Lin.Han@huawei.com>
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.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//++ciA=
Date: Fri, 20 Oct 2017 23:27:41 +0000
Message-ID: <1D30AF33624CDD4A99E8C395069A2A162CD76A38@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>
In-Reply-To: <832bcad24c7844a08985b6a96f531a93@XCH15-06-11.nw.nos.boeing.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59EA8673.0049, 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: add233d5f4d454c7c40dbb4b4f375f9c
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GnHGAmm4syN3daEuPQDHIptg0cc>
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: Fri, 20 Oct 2017 23:27:51 -0000


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

-----Original Message-----
From: Lin Han [mailto:Lin.Han@huawei.com] 

> ATM is failed due to many reasons, scalability is one of it.
> This solution is not intended to replace completely the best-effort 
> transport service. The solution is only for those application which 
> really needs a flow level QoS, such as AR/VR, tactile internet, etc. 
> From this sense, it does not sacrifice the scalability of IP.

Or at least, does not sacrifice it as much? ATM also had a UBR service.

[LH] Yeah, everything has cost. But it is still different, ATM UBR is connection oriented, it needs setup and involves the control protocol such as PNNI. In our case, the IP architecture is not touched at all. IP best effort is as simple as before. The new solution does not impact the IP routing or any other protocols.

But my point was only that out in the wild, you have no guarantee that the routers in the path will know what to do with your in-band QoS demands. Only in situations where all the routers are in your control will you have that guarantee. But sure, in walled gardens, these cool ideas can be made to work.
[LH] Agreed. But not that strict. As I said in the document, for optimization, the HbH router is only needed for the point of the congestion or device introducing a lot latency. It does not need all routers on the path to be HbH aware. And if a router cannot guarantee the bandwidth, the application can fall back to normal TCP, it does not completely disable the transport.
The basic idea still works for multiple domain, I don't want to talk about it since it may introduce more debating. Let see if there is any flaw for a single domain. If it works, I'm sure technically we don't have problem to apply to multiple domains. 
One more infor for this domain issue. The network environment that an application may need this QoS (ultra-high bandwidth and ultra-low latency) may be flat, and very likely has a few domains (one or two). This is because of the limit of propagation delay. For example, in the architecture of 5G that is supposed to support the latency as low as single digit ms, the content provider is supposed to connect to the SP's access network directly and in the same metro. Only this deployment can provide the physical distance as short as possible.

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 

Bert