Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF101

"Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com> Mon, 05 March 2018 08:09 UTC

Return-Path: <michael.scharf@nokia.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B301127023; Mon, 5 Mar 2018 00:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 c1_cpc6KJStH; Mon, 5 Mar 2018 00:09:43 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::71f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1B2126579; Mon, 5 Mar 2018 00:09:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O+Hk7qt2z7C/1CoIE2FGg58IsLx/lIpdqgOQ7jDcLLQ=; b=qtoGQE0pEvC/RCqLFcu5Z1PTN++S8yvzihogDK5hQAzEeMi60VWxKXC2hU7FKTMXtTAwEVDq5effag2Ykfp6cWartWiHDP6xY5CUnCr2w1Cnl5Ui9D5dX2h4V8Lq66h1gxSCu85AbuOy6G0HOt5j0D4TO9jOOFUpNLCVGYVSy7k=
Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2642.eurprd07.prod.outlook.com (10.173.92.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Mon, 5 Mar 2018 08:09:39 +0000
Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::4935:9288:dcd6:7db0]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::4935:9288:dcd6:7db0%5]) with mapi id 15.20.0567.011; Mon, 5 Mar 2018 08:09:39 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>
To: Yingzhen Qu <yingzhen.ietf@gmail.com>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>
CC: Thomas Nadeau <tnadeau@lucidvision.com>, "tcpm@ietf.org" <tcpm@ietf.org>, Yingzhen Qu <yingzhen.qu@huawei.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>
Thread-Topic: [tsvwg] Agenda requests for TSVWG@IETF101
Thread-Index: AQHTs31He8dVfiO+dEamE9tKlKhCoqO/3CkggAArYoCAAIi0AIAAt21Q
Date: Mon, 05 Mar 2018 08:09:39 +0000
Message-ID: <AM5PR0701MB25474AC4A52E38B43E543FA193DA0@AM5PR0701MB2547.eurprd07.prod.outlook.com>
References: <A1F61D20-1911-4A6E-9F80-A1DF1EF91816@huawei.com> <AM5PR0701MB254755BA63E33173CC7C7BCE93DB0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <5A9BEB65.6010102@erg.abdn.ac.uk> <CABY-gOO8sH3+5qfFj7DV6wh6+uX8CyBfwo4FBLi=9x1RngQDHg@mail.gmail.com>
In-Reply-To: <CABY-gOO8sH3+5qfFj7DV6wh6+uX8CyBfwo4FBLi=9x1RngQDHg@mail.gmail.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com;
x-originating-ip: [92.203.242.128]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2642; 7:LjrrmYiz5j6jYS+F7ZQCiJpCBoaeWT/U722/w/9mXTubHjD0r7BFEcqiBqPJV18IdX/xk7cpXHHiIvipNZkGv23tJCVgnijcMLPFeiesy4wPZWSMYu9Zo9uxsEuUBAeDYZ+HjF7mR8QvsC0W5DFMJgbrtrySsCcBg6ZQmhYVolNaGiWlN4uNToQF7dQEE3oNahm+d12N8iDAokzBI5pbBQU6L587f9CtagpyIAwMZKu7xLZvEdxR2CUo/hZaMayL
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 11c9d21a-8e45-418c-a36d-08d582707173
x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:AM5PR0701MB2642;
x-ms-traffictypediagnostic: AM5PR0701MB2642:
x-microsoft-antispam-prvs: <AM5PR0701MB2642B3E7A77662D24A94634793DA0@AM5PR0701MB2642.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(50582790962513)(82608151540597)(85827821059158)(130329453890623)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231220)(11241501184)(806099)(944501244)(52105095)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:AM5PR0701MB2642; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2642;
x-forefront-prvs: 06022AA85F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39380400002)(346002)(396003)(39860400002)(199004)(51914003)(189003)(53754006)(97736004)(54896002)(6436002)(6306002)(55016002)(76176011)(606006)(25786009)(186003)(14454004)(81166006)(86362001)(66066001)(39060400002)(81156014)(105586002)(2906002)(3280700002)(229853002)(236005)(9686003)(26005)(8676002)(99286004)(106356001)(316002)(74316002)(59450400001)(561944003)(3846002)(6116002)(7696005)(3660700001)(4326008)(19609705001)(102836004)(790700001)(966005)(6246003)(53936002)(6506007)(2501003)(5660300001)(5250100002)(54906003)(53546011)(8936002)(110136005)(2950100002)(68736007)(33656002)(93886005)(478600001)(2900100001)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2642; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 3tRv/rRpPd8PW6eFDkJmYTHigOFlbZp95YM4Y77WnSx7/ttYX49zHAJravTFvAxNvp0ktJhU5kT2XDgh1ww5Lo0mRgFq75utxVZ9d6szbGw62RP+8lT5yYVaII+trseoG76UuGEFd7tVhrOmbY6zEWs4WMn5hjYRKeLrBnacdV0N2AEXP135P3RWgCXQ5pZPz9l0ZV8ySVo1YxN7MGeqXUOyG+ffXBQ2rKeIvwkw6/oAsq+GNnOPrU5NXc/5uhwGLkq/vk2QQVtNOVtNnsENo9eCCGL4vH08uuEiamuNcXXYI+FRf/djmugQ77LRGZNHYtQmyigNjPP/VNE9iN7E/cVQwCJRLLM9+Z+RW/6qTj8Sw8C5HOw3QqTGSLcoQaFO
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25474AC4A52E38B43E543FA193DA0AM5PR0701MB2547_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 11c9d21a-8e45-418c-a36d-08d582707173
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2018 08:09:39.2944 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2642
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ovLrV5BOkkVgOpdJvCa1LJ5LjBg>
Subject: Re: [tcpm] [tsvwg] Agenda requests for TSVWG@IETF101
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2018 08:09:46 -0000

I believe that this proposal is similar to QuickStart TCP (RFC 4782), which is not cited in draft-han-tsvwg-cc, and the reference is also missing in draft-han-6man-in-band-signaling-for-transport-qos.

RFC 6077 explains some of the issues that an in-band signaling mechanism like Quick-Start has to solve. As far as I can tell, the fundamental challenge is neither the protocol specification nor a prototype implementation. For instance, it has been proven that QuickStart TCP can be implemented e.g. in network processors (see http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf).

So, when updating the documents, I suggest to add a discussion of how the open research issues explained in RFC 6077 are addressed.

Michael


From: Yingzhen Qu [mailto:yingzhen.ietf@gmail.com]
Sent: Sunday, March 04, 2018 9:59 PM
To: gorry@erg.abdn.ac.uk
Cc: Scharf, Michael (Nokia - DE/Stuttgart) <michael.scharf@nokia.com>; Thomas Nadeau <tnadeau@lucidvision.com>; tcpm@ietf.org; Yingzhen Qu <yingzhen.qu@huawei.com>; tsvwg@ietf.org; tsvwg-chairs@ietf.org
Subject: Re: [tsvwg] Agenda requests for TSVWG@IETF101

Hi Gorry and Michael,

Thanks for the suggestion, I'll request a presentation in ICCRG. Meanwhile, I think since the in-band signaling draft was presented in TSVWG, if time allows it still makes sense to present this draft in TSVWG.

The in-band signaling draft covers lots of aspects, and the required changes include network layer and transport layer. We're working on updating the draft, and may break it into pieces to fit different WGs.

Your comments and help are very much appreciated.

Thanks,
Yingzhen

On Sun, Mar 4, 2018 at 4:49 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk<mailto:gorry@erg.abdn.ac.uk>> wrote:
I am unsure yet what the correct group of people world be to explore a "Bandwidth Guaranteed Network". The presentation last IETF looked like the work could imply a need for changes proposed to the network layer (using OAM exchnages) to set the sending rate and make those bandwidth reservations.  In the end, it could result in a protocol quite different to TCP, I think this sort of change may possibly have a home in TSVWG  - but first I'd agree with Michaeland would encourage a presentation of the problem statement in ICCRG to explore the issues.

Gorry

On 04/03/2018, 10:34, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

Hi all,

From the abstract: “…This draft proposes a new TCP congestion control algorithm used in bandwidth guaranteed networks.  It is an extension to the current TCP standards.”

In the IETF, I believe the expertise for this specific document would be in TCPM, which in CC. If the authors are interested in feedback on the proposed mechanism, I would recommend to ask TCPM.

Alternatively, corresponding research could perhaps be performed in the ICCRG. ICCRG has published RFC 6077 to document some of the open research issues in this space.

Michael

*From:*tsvwg [mailto:tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>] *On Behalf Of *Yingzhen Qu
*Sent:* Sunday, March 04, 2018 6:55 AM
*To:* tsvwg@ietf.org<mailto:tsvwg@ietf.org>; tsvwg-chairs@ietf.org<mailto:tsvwg-chairs@ietf.org>
*Cc:* Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>
*Subject:* [tsvwg] Agenda requests for TSVWG@IETF101

Dear Chairs,

A new draft (The draft was suggested by TSVWG @IETF100) was just submitted, and we’d like to request a time slot to present it @IETF101.

Title:A New Congestion Control in Bandwidth Guaranteed Network

Presenter: Yingzhen Qu (Huawei)

Time required (including Q/A): 10 mins

Draft: https://datatracker.ietf.org/doc/draft-han-tsvwg-cc/

If there is any question, please kindly let us know.

Thanks,

Yingzhen