Re: [tsvwg] Prague requirements survey
Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Wed, 03 March 2021 14:00 UTC
Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A8F3A133D for <tsvwg@ietfa.amsl.com>; Wed, 3 Mar 2021 06:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 QUcGyeW64olC for <tsvwg@ietfa.amsl.com>; Wed, 3 Mar 2021 06:00:00 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80053.outbound.protection.outlook.com [40.107.8.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338233A133F for <tsvwg@ietf.org>; Wed, 3 Mar 2021 06:00:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZHa09eD4zWqpRmfyxFe5p4kPLeaFgqNT75UkxOZxbZJQXjLzJoLxvacCIbSqLnrGQIcPjTorCD1wvW/s4M+KJC+QhE9V9ZEzoRlOUSNBf/DK6JE2E87oUGFV9o1sdp/P84rDvLvTO89euCyEe+qBq2LpIKhAkcpUbpVHVDl2VA3HzyGaFwb+1eeH1+zV0UnqzPnL1Li25oKgztx+E6X0y0W3lDMf1TlcdF7c02JKtUxWLjEzhp7KyYqL4Dl4kOhAnGF2Mel2DiWfzkYqNLm+kWohcWBcHvXCHQGAKEdKqAGy9p9mRY2G8TmjGlMTD2x+0glvlcVQRd9DqD5QjAFkqA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v9JCDpcW69wMYCHgI0AARZeUbfa4WY5JeNXgPBI8u7U=; b=CMO5Bwa2jtM8JkKH3lR9SnIkuO21pI1Z9Ow1zJ8UVzXhywMMFUzMyUpuP7/ttgXmwhOnoRIthzOtZo8LOzOhSo1kDlVUBbX23EdlB/SeiyzFZt8Hof83t/qc8pXmxCx6yaITDnuXnieKkd/9rnByHqMiWxPvBu8MRWC3+9zbyPosG9ZRBWfPzFzAucLrOmwo0mlV+2SsweMji0as8fqgtIxidS3KhC6ghPHrkWkJYDS4g3YhiQZDqLoMXM/XzyNPMi3nvRSVccfGzgC823ZRbWof4kP387vt+AnfQBMcAnXuj2U/nW6JR4yGFHArbOs5LQ4IgTlGrL61SSQfzxNTcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v9JCDpcW69wMYCHgI0AARZeUbfa4WY5JeNXgPBI8u7U=; b=L7GlHqQ9VkP3776skrgCkNIxWRyas9TBwGgh3yQshN68AbjXs6SCc5Hkn9HnEHmA1fw9itqq81U7YU52tTcY+w+DI/HOeSUw5dxySZAzIvD/cxNAHNHXrWQlJiok17dRHhfPobvX/lAD1bMGYBT7EcNO3FsaL1bPsvUKsCIWVlU=
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com (2603:10a6:3:6c::8) by HE1PR07MB3065.eurprd07.prod.outlook.com (2603:10a6:7:35::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.15; Wed, 3 Mar 2021 13:59:56 +0000
Received: from HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57]) by HE1PR0701MB2299.eurprd07.prod.outlook.com ([fe80::a087:95cb:e76b:d57%10]) with mapi id 15.20.3912.017; Wed, 3 Mar 2021 13:59:56 +0000
From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Prague requirements survey
Thread-Index: AdbzPLYWoHtOCowHQ0uox2aN7ECzHgE/jRFAASKPXuAATuD/IAAGkG8AAFuTK9ACdEFagAAZQAQwABEtSwAAMEy08AEjoXwAADgxFMA=
Date: Wed, 03 Mar 2021 13:59:56 +0000
Message-ID: <HE1PR0701MB2299B39074FB92FB68DC7E53C2989@HE1PR0701MB2299.eurprd07.prod.outlook.com>
References: <AM8PR07MB7476A907FDD0A49ADBD7CA7EB9BD0@AM8PR07MB7476.eurprd07.prod.outlook.com> <SN2PR00MB017475FC0E8C13754E531E17B6B69@SN2PR00MB0174.namprd00.prod.outlook.com> <AM8PR07MB7476FAE559719D241375A816B9B19@AM8PR07MB7476.eurprd07.prod.outlook.com> <HE1PR0701MB22999C8C05ECA3D995FA7FFEC28F9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <AM8PR07MB7476E0EB3FC368D3C69A5466B98F9@AM8PR07MB7476.eurprd07.prod.outlook.com> <HE1PR0701MB229971850F775AD5DD1855FDC28D9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <f4b73d65-1449-426b-c8f8-5540f047dd49@bobbriscoe.net> <HE1PR0701MB229930BB8F058B2D874C7FA3C2809@HE1PR0701MB2299.eurprd07.prod.outlook.com> <c292543e-daca-cc39-7e8c-880d5130eaa8@bobbriscoe.net> <HE1PR0701MB229964E344210C5A2AD57366C29F9@HE1PR0701MB2299.eurprd07.prod.outlook.com> <27161ac3-e306-f021-7894-3ee534f87c36@bobbriscoe.net>
In-Reply-To: <27161ac3-e306-f021-7894-3ee534f87c36@bobbriscoe.net>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.227.122.88]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c2e4cd15-110c-4b64-22fb-08d8de4ca0b0
x-ms-traffictypediagnostic: HE1PR07MB3065:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR07MB3065218599CD6896856B7019C2989@HE1PR07MB3065.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:4125;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FC9zUtDEs9PmCz1Pzjd9KaEhiopWKwk5QjL1leZyg55gQeIKu84NW5dYBpRMEK5sJM3O6XEm9grHmNi6+zmoYc6ZJ3KUilEPABtdtDPf3Hc0PCR4y2xKAZf5+ygU9GonMeNz2S8HJqCWLNQTcY8kjhoHhStJnICpBTDgqCuRilKM3E0ca/utJXsLcFbWV4/pObPMRLFUt8nsAkhcw2tdipfLqRmRXGOOEm/76ReTP9gsUD3/2ae1msCw8CinzcticitGz4VJqiT68CM6+HSwJt6rRLG9yudKlj/Mp3+vwvyH7n0sVf36LfzjXfgiAccYAemOEptCU2U7EbNepISOyu3QGcIkr6f3BSfERyvQb06KNKNdnQ78JpbuVrNNsdUqpDO7otrW+qv1GfF3FXdqiCBII+HeHS3w0m7UGSSGJrFWwCFLSbWdncko0q7nMUDpJZ5vfeWV4FMUjOTenXFOl6B0GF/8wESTzUqmaxYisroOFXq6xnR+l5CD5C464Jl3yo2eLiG+q/yT4OejSpDldrozxbaGbQqu0P9BNtUykozF7GRPm5OtudNMxrqZuE5pcywWGBFVzNifjFvyQ/KAqA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB2299.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39860400002)(396003)(136003)(376002)(4326008)(7696005)(966005)(83380400001)(99936003)(107886003)(86362001)(53546011)(166002)(6506007)(2906002)(186003)(26005)(110136005)(55016002)(9686003)(316002)(5660300002)(9326002)(478600001)(33656002)(71200400001)(66616009)(8676002)(66476007)(66556008)(76116006)(66946007)(52536014)(8936002)(64756008)(66446008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 90EYJOtvcTtlqjO0HRwNkrvfm+NcRz7sSYRhre04M4+gb61pDS7x4FlbhbB2ZovK8Sh1tKKlzlx6ODRUqPr1T2zOYLikH5ya4vHdsnqMHw7FB32NYhk4Qf3Tlo32YkXGE8HQY6z8jK/7+hikF0uaSeofZxsu38A0IAEvISdxqXuFRSBprnamP5sJawL1F2eMrRbGV8tA+PZ3fwjR4tDcBZ7e3Rx13T24fSKfamdDlDFfoie2DmWlPPcde7d+FrUKf3v8L+gLPuHoBRge1P+n0XNDghkEnKYUMgwekcHNbVDut08kfEUDpb7cyI7fjzPYY/cWNlJmFbkbF1c/WFeAe9rx/EgC9RD+C0pG+a9JOzcJ/mU4lvbO2UAT6syCZEJirWw1nLDBgpDqVKyrgrzDRZ/jFP0YpEf6Cvvwl66rzfO5Gvq9olM4MsqfJR5zeQfWX9ffgdleXHRqyNczZ+claGtBLpUcNgYnx3i035Xdul0CDpx1lqVqnZGZ6CtON3dgneNyAyIYlWLBiprhidCmo/1SWUgJjezPa3f5aS/qETAzl6nkvO9Zi40F69YL/BvR1Vvyo3cR/spVRNcqiaIYjhbNm/+7LjdZ2K0FliCYq6SJra+FYGj4d3YI9DwdVWti5XMODU9rkKg66j5os0SwlUXfMU/dSWvj5VcSRmOAMmMMYXmlqjuIATFttlSJUCgB9Fn5fpSMMhXqgHgnlxr61Nsrl16skjZNxc5L17byUhJmVuikS62Zs24EzHMJSaKj5hLgydmpodvWAkdjNBGiXdCMe9yzsSpUGiZs+QFW8Th1qT61w/hWK69s2UF4LD7+UpCniCfOhOVY3MQbf3cU2qVhDelyGvbP1LTyMwUqPxFOYSJ1BCaCBjbAONYXsq6EptfdKQK1aYNS5GsW2sufWjugv+Za3eAbUyuLSTa8AS6eCe9peayKFTfYRN2uMvZqvgF/zv92Bmy21QAOEItzCpIq/1sz5vgVyemCf1l7dJdDHnW6dBCNhZA7ZV+wT6SHToaX2kbgDqaIaSW81Ta0erLlIYL7LMIvhfYrNTosQNRMkPtqOZ0lRywDbwGBGsNiKA4xkJnYu0nddHahiGb1wvDpB3/gMjZEK2+46fBpLEuLVEIggggrQt76uOHYUYDN/JWTojePF780M+e6r1B+VpVLOQWONFVRtux/t4p4d09ufbfSBnhOEplA5arw/XYhECuAgYAXfC3Aeio9GVsa+3dkrh/sApjF5GS7+XUnQ6EKJZ0UI9p1O5MvO5dJU4EgxivY0SYHCtng95OX83Aps0CX4M6Tycl3dGjJgQEQPrsDp3cJJDePUZbQzUHSGpzI
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_05E4_01D7103D.DF256BA0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB2299.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c2e4cd15-110c-4b64-22fb-08d8de4ca0b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2021 13:59:56.6704 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lO76n481QQ3xvlg2U0rQzM0YF/f+Jse3f+46hBugxp4nsMOb21zvCGFRTJ57EVzzQpU1Wo8Q65IdbcNq2mdG0fnhryapoTtx1k/hNKY7nIhh0/tOYw/uBbZtAAHJQU4M
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3065
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UrJELM-1gUWDKVOnbB9_m7bpHpM>
Subject: Re: [tsvwg] Prague requirements survey
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 14:00:05 -0000
Hi Please see below [IJ4] /Ingemar From: Bob Briscoe <ietf@bobbriscoe.net> Sent: den 2 mars 2021 12:04 To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com>; tsvwg IETF list <tsvwg@ietf.org> Subject: Re: [tsvwg] Prague requirements survey Ingemar, inline [BB3] On 24/02/2021 16:01, Ingemar Johansson S wrote: Hi Inline [IJ3] /Ingemar From: Bob Briscoe <mailto:ietf@bobbriscoe.net> <ietf@bobbriscoe.net> Sent: den 23 februari 2021 17:50 To: Ingemar Johansson S <mailto:ingemar.s.johansson@ericsson.com> <ingemar.s.johansson@ericsson.com>; De Schepper, Koen (Nokia - BE/Antwerp) <mailto:koen.de_schepper@nokia-bell-labs.com> <koen.de_schepper@nokia-bell-labs.com>; tsvwg IETF list <mailto:tsvwg@ietf.org> <tsvwg@ietf.org> Subject: Re: [tsvwg] Prague requirements survey Ingemar, - see inline [BB2] On 23/02/2021 08:45, Ingemar Johansson S wrote: Hi Bob Please see inline [IJ2] From: Bob Briscoe <mailto:in@bobbriscoe.net> <in@bobbriscoe.net> Sent: den 22 februari 2021 21:35 To: Ingemar Johansson S <mailto:ingemar.s.johansson@ericsson.com> <ingemar.s.johansson@ericsson.com>; De Schepper, Koen (Nokia - BE/Antwerp) <mailto:koen.de_schepper@nokia-bell-labs.com> <koen.de_schepper@nokia-bell-labs.com>; tsvwg IETF list <mailto:tsvwg@ietf.org> <tsvwg@ietf.org> Subject: Re: [tsvwg] Prague requirements survey Ingemar, On 10/02/2021 09:09, Ingemar Johansson S wrote: Hi Please see inline /Ingemar From: De Schepper, Koen (Nokia - BE/Antwerp) <mailto:koen.de_schepper@nokia-bell-labs.com> <koen.de_schepper@nokia-bell-labs.com> Sent: den 8 februari 2021 14:37 To: Ingemar Johansson S <mailto:ingemar.s.johansson@ericsson.com> <ingemar.s.johansson@ericsson.com>; tsvwg IETF list <mailto:tsvwg@ietf.org> <tsvwg@ietf.org> Subject: RE: Prague requirements survey Hi Ingemar, Thanks for your contributions. I linked your doc to the https://l4steam.github.io/#prague-requirements-compliance <https://protect2.fireeye.com/v1/url?k=ae271499-f1bc2db2-ae275402-866038973a 15-a6d18987ee63d9e2&q=1&e=4b98878d-2d51-48b6-9518-92696e72501d&u=https%3A%2F %2Fl4steam.github.io%2F%23prague-requirements-compliance> web page (and will do so for others). [IJ] OK, great! I didn't see any issues or objections mentioned to the current requirements as specified in the draft. Does this mean you think they are all reasonable, valid and feasible? [IJ] There is a slight possibility that I misunderstood parts of the layout. Even though SCReAM is only partially compliant in many cases I believe that requirements are reasonable. Interesting observation (related to the performance optimization topic 1) that for the control packets "RTCP is likely not using ECT(1)". Why is this not likely? I assume this will impact the performance? Do we need to recommend the use of ECT(1) on RTCP packets in the draft? [IJ] Upon first glance I don't see that it is beneficial that RTCP packets are ECT(1). But of course there is a possibility that RTCP packets go into a queue with higher latency and that may affect performance. So. perhaps it is reasonable that RTCP packets are ECT(1) too, but these are then to be regarded as non queue building as it can be hard to rate control RTCP. [BB] My knowledge is outdated, but RTCP used to be rate controlled in multicast to prevent implosion (that was in the early days on shared multicast, not single source). Are you saying all rate control mechanisms have been removed? Is the problem that there's no feedback channel for congestion indications on feedback? In 2-way RTP at least, couldn't you infer the congestion of RTCP datagrams from the ECN on data running alongside it? Or might they be disjoint paths? [IJ2] Yes. It would of course be possible to set ECT(1) on RTCP/UDP/IP packets and determine how large share of these packets that are marked. The problem is then that there is not (currently) any RTCP feedback(on feedback) format to carry that information back to the RTCP sender (==streaming client) to make some rate control of the RTCP feedback possible. The RTCP bandwidth is indeed limited, the rule of thumb is that it should be less than 5% of the RTP media bitrate scaled down by the number of receivers. SCReAM is just one receiver and the RTCP bitrate is roughly 2% of the medial bitrate. [BB2] Maybe what I said above didn't make sense, so I'll try saying it a different way... Imagine this bidirectional scenario where X and Y are sending r-t data to each other: 1a. X --RTP--> Y 1b. X <-RTCP-- Y 2a. X <--RTP-- Y 2b. X --RTCP-> Y Why can't Y use the proportion of ECN on the arriving RTP stream (1a) to infer the likely ECN on RTCP stream 2b? and Why can't X use the proportion of ECN on the arriving RTP stream (2a) to infer the likely ECN on RTCP stream 1b? you Then I thought maybe one can't be sure that 1a and 2b are actually traversing the same path. Similarly for 1b and 2a. [IJ3] RTP and RTCP is quite likely to traverse the same path, the difference may of course be if RTP is L4S capable and RTCP is not, for this reason it can make sense to have RTCP L4S capable as well. And you are right, as they traverse the same path then the RTCP traffic is equally likely to become marked as the RTP traffic. The question I have is how one congestion control RTCP and if it is needed, it is after all a small fraction of the media bitrate. Currently there is no available mechanism for this in the IETF standards that cover RTCP (at least it is unknown to me). [BB3] This is OK then, isn't it? I think this means the media receiver can set ECT on RTCP packets, at least for 2-way media sessions. Because: a) RTCP is a small fraction of the media bit-rate b) the media receiver can tell if congestion rises c) Even tho the media receiver currently has no code to regulate the RTCP stream, if congestion persists it will at least reduce its own parallel RTP stream even more to compensate. d) There's always the fall-back that if RTCP congestion is not cleared, the queue will progress from ECN to drop and naturally thin out enough RTCP datagrams. If RTCP congestion became a widespread problem in the future, code could be added to slow down the RTCP stream driven by congestion notifications in the parallel RTP media stream. Incremental deployment would be possible (I mean, the congestion info is already there, so each end could deploy unilaterally, without needing additional negotiation at session set up). [IJ4] Agree with the statements above. RTCP congestion should become a noticeable problem only for very asymmetric links, and there are possibly solutions for this, similar to the ACK rate negotiation in TCPM. But I guess one need to see evidence that it is really a problem . Bob PS. Sry for delayed reply. Bob Incidentally, the attitude being taken to ECT on TCP Pure ACKs in AccECN is in the AccECN draft. Basically, the info is now there for Ack CC if needed, but no need to use it currently. Bob Thanks, Koen. From: Ingemar Johansson S <ingemar.s.johansson@ericsson.com <mailto:ingemar.s.johansson@ericsson.com> > Sent: Monday, February 8, 2021 10:59 AM To: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com <mailto:koen.de_schepper@nokia-bell-labs.com> >; tsvwg IETF list <tsvwg@ietf.org <mailto:tsvwg@ietf.org> > Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com <mailto:ingemar.s.johansson@ericsson.com> > Subject: RE: Prague requirements survey Hi Please find attached (hopefully) a Prague requirements survey applied to SCReAM (RFC8298 std + running code) Regards Ingemar From: tsvwg <tsvwg-bounces@ietf.org <mailto:tsvwg-bounces@ietf.org> > On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp) Sent: den 6 februari 2021 23:20 To: tsvwg IETF list <tsvwg@ietf.org <mailto:tsvwg@ietf.org> > Subject: [tsvwg] Prague requirements survey Hi all, To get a better understanding on the level of consensus on the Prague requirements, we prepared an overview document listing the L4S-ID draft requirements specific to the CC (wider Prague requirements), as a questionnaire towards potential CC developers. If you are developing or have developed an L4S congestion control, you can describe the status of your ongoing development in the second last column. If you cannot share status, or plan-to/would implement an L4S CC, you can list what you would want to support (see feasible). In the last column you can put any description/limitations/remarks/explanations related to evaluations, implementations and/or plans (will implement or will not implement). Any expected or experienced issues and any objections/disagreements to the requirement can be explained and colored appropriately. The document can be found on following link: https://raw.githubusercontent.com/L4STeam/l4steam.github.io/master/PragueReq s/Prague_requirements_Compliance_and_Objections_template.docx <https://protect2.fireeye.com/v1/url?k=d16bc960-8ef0f066-d16b89fb-86ee86bd51 07-080c65bfd839440d&q=1&e=7dbb7494-67c3-4315-88a6-325f32e4e8b1&u=https%3A%2F %2Fraw.githubusercontent.com%2FL4STeam%2Fl4steam.github.io%2Fmaster%2FPrague Reqs%2FPrague_requirements_Compliance_and_Objections_template.docx> As an example I filled it for the Linux TCP-Prague implementation on following link: https://l4steam.github.io/PragueReqs/Prague_requirements_Compliance_and_Obje ctions_Linux_TCP-Prague.docx <https://protect2.fireeye.com/v1/url?k=f839c5f7-a7a2fcf1-f839856c-86ee86bd51 07-29dabadc5d0e673d&q=1&e=7dbb7494-67c3-4315-88a6-325f32e4e8b1&u=https%3A%2F %2Fl4steam.github.io%2FPragueReqs%2FPrague_requirements_Compliance_and_Objec tions_Linux_TCP-Prague.docx> Please send your filled document to the list (Not sure if an attachment will work, so I assume you also need to store it somewhere and send a link to it, or send to me directly). We hope to collect many answers, understanding the position of the different (potential) implementers and come faster to consensus. Thanks, Koen. -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ <https://protect2.fireeye.com/v1/url?k=9e93ec25-c108d525-9e93acbe-86fc6812c3 61-6ce26fbc5b7d3fe4&q=1&e=9dde995b-c278-4be1-a612-c70ef0067fc2&u=http%3A%2F% 2Fbobbriscoe.net%2F> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ <https://protect2.fireeye.com/v1/url?k=9c972e29-c30c1729-9c976eb2-86fc6812c3 61-770acfd11988f54b&q=1&e=67990d9c-a717-4edd-bfdc-2431e035aa8b&u=http%3A%2F% 2Fbobbriscoe.net%2F> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ <https://protect2.fireeye.com/v1/url?k=02ba5ced-5d21658c-02ba1c76-86d8a30ca4 2b-37bb9c60aa1867ee&q=1&e=90ac969e-38c0-44a8-a7f0-5fb69e6e3d78&u=http%3A%2F% 2Fbobbriscoe.net%2F>
- [tsvwg] Prague requirements survey De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Prague requirements survey Ingemar Johansson S
- Re: [tsvwg] Prague requirements survey De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Prague requirements survey Ingemar Johansson S
- Re: [tsvwg] Prague requirements survey Bob Briscoe
- Re: [tsvwg] Prague requirements survey Ingemar Johansson S
- Re: [tsvwg] Prague requirements survey Bob Briscoe
- Re: [tsvwg] Prague requirements survey Ingemar Johansson S
- Re: [tsvwg] Prague requirements survey Bob Briscoe
- Re: [tsvwg] Prague requirements survey De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Prague requirements survey Ingemar Johansson S
- Re: [tsvwg] Prague requirements survey De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Prague requirements survey Bob Briscoe
- Re: [tsvwg] Prague requirements survey De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Prague requirements survey Neal Cardwell
- Re: [tsvwg] Prague requirements survey Sebastian Moeller
- Re: [tsvwg] Prague requirements survey Vidhi Goel
- Re: [tsvwg] Prague requirements survey Vidhi Goel
- Re: [tsvwg] Prague requirements survey Sebastian Moeller
- Re: [tsvwg] Prague requirements survey Vidhi Goel
- Re: [tsvwg] Prague requirements survey De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Prague requirements survey Sebastian Moeller
- Re: [tsvwg] Prague requirements survey De Schepper, Koen (Nokia - BE/Antwerp)
- Re: [tsvwg] Prague requirements survey Sebastian Moeller
- Re: [tsvwg] Prague requirements survey Sebastian Moeller
- Re: [tsvwg] Prague requirements survey Ingemar Johansson S
- Re: [tsvwg] Prague requirements survey Bob Briscoe
- Re: [tsvwg] Prague requirements survey Vidhi Goel
- Re: [tsvwg] Prague requirements survey Bob Briscoe