IETF Logo Mail Archive

Re: [Plus] Status of PLUS

Lin Han <Lin.Han@huawei.com> Mon, 06 March 2017 01:46 UTC

Return-Path: <Lin.Han@huawei.com>
X-Original-To: plus@ietfa.amsl.com
Delivered-To: plus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D9C12948E for <plus@ietfa.amsl.com>; Sun, 5 Mar 2017 17:46:09 -0800 (PST)
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, 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] 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 wOttuG_ERpPi for <plus@ietfa.amsl.com>; Sun, 5 Mar 2017 17:46:07 -0800 (PST)
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 5C598126D73 for <plus@ietf.org>; Sun, 5 Mar 2017 17:46:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DII79384; Mon, 06 Mar 2017 01:46:01 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Mar 2017 01:45:32 +0000
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Sun, 5 Mar 2017 17:45:19 -0800
From: Lin Han <Lin.Han@huawei.com>
To: 'Spencer Dawkins at IETF' <spencerdawkins.ietf@gmail.com>, Brian Trammell <ietf@trammell.ch>
Thread-Topic: [Plus] Status of PLUS
Thread-Index: AQHSkhoYlGVJOx+2zEqT2+XBVOCrr6GHDjGQ
Date: Mon, 06 Mar 2017 01:45:17 +0000
Message-ID: <1D30AF33624CDD4A99E8C395069A2A162C223ECA@SJCEML702-CHM.china.huawei.com>
References: <28F27305-3F58-4091-857C-4BD4BEE8093C@trammell.ch> <E5F420F7-6B91-4E00-A434-A2A9B77DA3C8@trammell.ch> <CAKKJt-fE3h5eRMgbgT=a2C+0M3AsBYiJSn1sA-YwDOkO0PH8RQ@mail.gmail.com>
In-Reply-To: <CAKKJt-fE3h5eRMgbgT=a2C+0M3AsBYiJSn1sA-YwDOkO0PH8RQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.244.161]
Content-Type: multipart/alternative; boundary="_000_1D30AF33624CDD4A99E8C395069A2A162C223ECASJCEML702CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58BCBF5B.0126, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4739aba14693715baaabf64617d3f426
Archived-At: <https://mailarchive.ietf.org/arch/msg/plus/9KAuLMQpEv3LnuK3mYJM7k7RbmU>
Cc: "plus@ietf.org" <plus@ietf.org>
Subject: Re: [Plus] Status of PLUS
X-BeenThere: plus@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." <plus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plus>, <mailto:plus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/plus/>
List-Post: <mailto:plus@ietf.org>
List-Help: <mailto:plus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plus>, <mailto:plus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2017 01:46:10 -0000

Hi, Spencer, Brain



Thanks for your reply



We think that the current transport layer lacks a simple way to provide more fine granularity control to the quality of service, such as the bandwidth and latency. For this requirement, the current scheme using DSCP or ECN is far from enough. And using a separate protocol such as RSVP is not scalable and convenient. If the transport itself has a intrinsic signaling capability to the network device, it will make such feature controllable by user or application directly. And importantly, a QoS service with user control is the requirement of compliance to the network neutrality.

We have analyzed the AR&VR requirements, it turns out that TCP/UDP hardly provide a support of couple of hundred Mbps to Gbps bandwidth plus the single digit ms latency if we still use the fair queuing based algorithm in the forwarding. To overcome such difficulty, we need to provide extra information to network hardware for different queuing algorithm.

I have asked QUIC to add more extension room to support network device signaling, but rejected due to its current chartering scope. So, I think PLUS could potentially do such job if we have more support from industry.



Regards



Lin


From: Plus [mailto:plus-bounces@ietf.org] On Behalf Of Spencer Dawkins at IETF
Sent: Tuesday, February 28, 2017 3:26 PM
To: Brian Trammell
Cc: plus@ietf.org
Subject: Re: [Plus] Status of PLUS



On Feb 28, 2017 16:56, "Brian Trammell" <ietf@trammell.ch<mailto:ietf@trammell.ch>> wrote:
Hi, Lin, all,

Circling back on these points...

> On 14 Feb 2017, at 22:38, Lin Han <Lin.Han@huawei.com<mailto:Lin.Han@huawei.com>> wrote:
>
> Hello, all
>
> Just signed up this list, I knew PLUS has been concluded unfortunately.

In the sense that the BoF failed to come to consensus that a working group could be formed with the presented scope, due to questions about the privacy risk / utility tradeoff of a generalized solution to the problem of replacing implicit interference by path elements with explicit communication, yes... I would not yet say we've come to a "conclusion" yet, though.

It's worth saying that I agree with Brian's summary.

Spencer, as responsible AD for PLUS

v2.23.0 | Report a Bug | By Email