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

Tuboyan <tuboyan@huawei.com> Mon, 23 October 2017 03:17 UTC

Return-Path: <tuboyan@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 5F50A13CF0E for <ipv6@ietfa.amsl.com>; Sun, 22 Oct 2017 20:17:18 -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 NiU3RS7EmxZo for <ipv6@ietfa.amsl.com>; Sun, 22 Oct 2017 20:17:16 -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 B05BE13CF0B for <ipv6@ietf.org>; Sun, 22 Oct 2017 20:17:15 -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 DYG19119; Mon, 23 Oct 2017 03:17:14 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 23 Oct 2017 04:17:13 +0100
Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.36]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 23 Oct 2017 11:17:08 +0800
From: Tuboyan <tuboyan@huawei.com>
To: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>, Mark Smith <markzzzsmith@gmail.com>
CC: 6man WG <ipv6@ietf.org>
Subject: 答复: 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: AQHTSTlPtaI95VpGm0KV6fdGmcn50aLrYoqAgAEplICAAAakgIAASruAgALnUYCAADeyAIAAyf1g
Date: Mon, 23 Oct 2017 03:17:08 +0000
Message-ID: <9183E046F3015645850901915FF624927334CC80@nkgeml514-mbs.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> <CAO42Z2zbZSbqQkjkVg0DPnCAT_b61VmYLf6C-2ZnPJ23_PnkEA@mail.gmail.com> <966a3fad3a14484cba3d9494135913f0@XCH15-06-11.nw.nos.boeing.com>
In-Reply-To: <966a3fad3a14484cba3d9494135913f0@XCH15-06-11.nw.nos.boeing.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.155.242]
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.0A090205.59ED5F3A.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.36, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ed51a0ab918d04e08cb12929afd71511
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zjpy5gQX7MpiJxhpFMgrO-4gPUg>
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: Mon, 23 Oct 2017 03:17:18 -0000

Hi Bert,

-----邮件原件-----
发件人: ipv6 [mailto:ipv6-bounces@ietf.org] 代表 Manfredi, Albert E
发送时间: 2017年10月23日 7:07
收件人: Mark Smith
抄送: 6man WG
主题: RE: Hop-by-hop [not draft-han-6man-in-band-signaling-for-transport-qos-00.txt]

From: Mark Smith [mailto:markzzzsmith@gmail.com] 

> From: Lin Han [mailto:Lin.Han@huawei.com]

>> [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.
>
> Not at all.
>
> You're creating state in the forwarding plane. State created based on 
> traffic characteristics  is vulnerable to state exhaustion attacks.

I think that all Lin was saying was, "if you use best effort, then you haven’t sacrificed scalability." Which is true enough, I think. Whereas, with ATM, you are still having to set up that VC ahead of time, even if, with UBR service, you aren't specifying any QoS requirements along that path.

> Even in closed domains this can be an issue, because "closed" domains 
> attached to the Internet aren't guarateed to stay closed.

Yes, although I think Lin was saying, if you encounter routers that don’t know diddly about his in-band signaling, AND these routers aren't particularly congested, then all should still work fine. This traffic would hopefully sail through these lightly loaded inter-carrier routers, and then the QoS knobs would come into play in his own ISP network.

> RFC791 and RFC8200 forwarding is stateless.
>
> I'd even say traffic created state is worse than connection oriented 
> state such as switched virtual circuits in ATM. In that model, hosts 
> are requesting permission to send traffic on the network before 
> they're able to - if the network can't set up a connection for a host, 
> the host cannot contribute traffic load to the network.

That's been my reaction here too. I think, at a most fundamental level, IP is a technique that allows for plenty of *cheap bandwidth*, which has made QoS guarantees mostly unnecessary. Cheap bandwidth allows, even begs for over-provisioning in the network, which makes complicated QoS guarantees unnecessary. And furthermore, apps that do require certain quality levels take it upon themselves to adjust to what's available, rather than giving that responsibility to the intervening network. I think that RTP/RTSP was quite revolutionary, in the telecom world.

[BoyanTu] Without help from network, even app in host can adjust to what's available, but app still cannot get bandwidth it need ,such as VR steam service. 

On the other hand, schemes like ATM assume *expensive bandwidth*, so they make a big deal about doling out bandwidth with fine granularity. Or, more realistically, they optimistically created the knobs for doing so, which proved way too complicated, in the face of the "cheap bandwidth" connectionless IP competition of the day. But there has been a succession of efforts, from early on in IP, to add QoS knobs.

Bert

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------