Re: [tsvwg] Prague requirements survey

Bob Briscoe <ietf@bobbriscoe.net> Tue, 23 February 2021 16:50 UTC

Return-Path: <ietf@bobbriscoe.net>
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 BDF013A09F6 for <tsvwg@ietfa.amsl.com>; Tue, 23 Feb 2021 08:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.333
X-Spam-Level:
X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 EMCZmSUgiEQJ for <tsvwg@ietfa.amsl.com>; Tue, 23 Feb 2021 08:50:20 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 C7B0F3A0ADB for <tsvwg@ietf.org>; Tue, 23 Feb 2021 08:50:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OTzpZBPXvIstiwetgbJnZUPDedsMODIZ6/hdVAaRP4o=; b=aQ5JOXbf9e5+cOa3vaf98Myl3 5EFBclkX60alufPNQh/UKndAzd3i8aCTJp4y+IFHlxjllx8chlpB59vYYMygvyifDEt3MrT7LC8xj jDjiPSmBfX8B56S1vNgO5JZD6gVUdvVlKjeT72Q5ZWqfoXjnbJ05EcJxfqxosIODM0Q3OkxOMe6nr OOnGcrjMYReyOK2RYOWWDRnsPmCQ8Z5E9ElhinT+eYQyrR0OsmYaa2DSfzJmoHF4qReZEa01nmGBN sLWF1Eov2Cj3v7DeTFWBH82Cq/Rn07Ct1QAdHwqZA66QEQzsx+IrXR2q+PqC7zEFyYKpsR/UzJ4pl T8DfirTwA==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:48474 helo=[192.168.1.9]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lEat6-0008Jf-BL; Tue, 23 Feb 2021 16:50:16 +0000
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>
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>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <c292543e-daca-cc39-7e8c-880d5130eaa8@bobbriscoe.net>
Date: Tue, 23 Feb 2021 16:50:14 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <HE1PR0701MB229930BB8F058B2D874C7FA3C2809@HE1PR0701MB2299.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------B9B53C6E8BEEF877636A363E"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hosting.co.uk
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/A6AXGlbAuTuCdnAcVABst8eGo5w>
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: Tue, 23 Feb 2021 16:50:28 -0000

Ingemar, - see inline [BB2]

On 23/02/2021 08:45, Ingemar Johansson S wrote:
>
> Hi Bob
>
> Please see inline [IJ2]
>
> *From:* Bob Briscoe <in@bobbriscoe.net>
> *Sent:* den 22 februari 2021 21:35
> *To:* Ingemar Johansson S <ingemar.s.johansson@ericsson.com>om>; De 
> Schepper, Koen (Nokia - BE/Antwerp) 
> <koen.de_schepper@nokia-bell-labs.com>om>; tsvwg IETF list <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)
>     <koen.de_schepper@nokia-bell-labs.com>
>     <mailto:koen.de_schepper@nokia-bell-labs.com>
>     *Sent:* den 8 februari 2021 14:37
>     *To:* Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
>     <mailto:ingemar.s.johansson@ericsson.com>; tsvwg IETF list
>     <tsvwg@ietf.org> <mailto: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-866038973a15-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.


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/PragueReqs/Prague_requirements_Compliance_and_Objections_template.docx
>     <https://protect2.fireeye.com/v1/url?k=d16bc960-8ef0f066-d16b89fb-86ee86bd5107-080c65bfd839440d&q=1&e=7dbb7494-67c3-4315-88a6-325f32e4e8b1&u=https%3A%2F%2Fraw.githubusercontent.com%2FL4STeam%2Fl4steam.github.io%2Fmaster%2FPragueReqs%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_Objections_Linux_TCP-Prague.docx
>     <https://protect2.fireeye.com/v1/url?k=f839c5f7-a7a2fcf1-f839856c-86ee86bd5107-29dabadc5d0e673d&q=1&e=7dbb7494-67c3-4315-88a6-325f32e4e8b1&u=https%3A%2F%2Fl4steam.github.io%2FPragueReqs%2FPrague_requirements_Compliance_and_Objections_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 Briscoehttp://bobbriscoe.net/  <https://protect2.fireeye.com/v1/url?k=9e93ec25-c108d525-9e93acbe-86fc6812c361-6ce26fbc5b7d3fe4&q=1&e=9dde995b-c278-4be1-a612-c70ef0067fc2&u=http%3A%2F%2Fbobbriscoe.net%2F>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/