Re: [tsvwg] Prague requirements survey

Bob Briscoe <in@bobbriscoe.net> Thu, 06 May 2021 21:49 UTC

Return-Path: <in@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 194DB3A0922 for <tsvwg@ietfa.amsl.com>; Thu, 6 May 2021 14:49:18 -0700 (PDT)
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 p8y3B1nsiBet for <tsvwg@ietfa.amsl.com>; Thu, 6 May 2021 14:49:13 -0700 (PDT)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.85.90]) (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 8893E3A091F for <tsvwg@ietf.org>; Thu, 6 May 2021 14:49:12 -0700 (PDT)
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:Cc:To:Subject:Sender:Reply-To: 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=cW2/ognanGRShyx+Jni9EMiNG0g/jiGlgREE7Sm/6hc=; b=0QvXxMryhRJMe6L+vTQGaCAfSx elkLG0rrcSexESagFS7Kr6qz7mhkssbt4dGW2z9x0tuWg/J77ZTchrKNKZBlfv0QzwyN3b+nXmyXA iozzXAO479DPTYGysWzCQwF8rWaqveiHvBtNkFuwkaONoH2OLlk2O98RqCKWWoNnbuvBbZZkXs5qx M6JzvyefvJtPMqwUNnKNwQXVhHpFEhnkoG1MbzsZ07iATLQB538LcP6j3HvdPvK13gNSxhdpyh8UP juV5H9TXzlIG51yoVgI+1Hcify/l4PJfI9kkC/6fRta+awHum0YnViy2+uMZ0zFfjEWBcw6ftyaKv v2AHpUVA==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:59774 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <in@bobbriscoe.net>) id 1lelrm-0003FY-32; Thu, 06 May 2021 22:49:03 +0100
To: "De Schepper, Koen (Nokia - BE/Antwerp)" <koen.de_schepper@nokia-bell-labs.com>, Vidhi Goel <vidhi_goel@apple.com>, Neal Cardwell <ncardwell@google.com>
Cc: tsvwg IETF list <tsvwg@ietf.org>, Nandita Dukkipati <nanditad@google.com>, Praveen Balasubramanian <pravb@microsoft.com>, Priyaranjan Jha <priyarjha@google.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> <DBBPR07MB7481E1026CDE30D494856F15B9989@DBBPR07MB7481.eurprd07.prod.outlook.com> <AM8PR07MB7476FAEF53518DBFE457AC62B9949@AM8PR07MB7476.eurprd07.prod.outlook.com> <AM8PR07MB747629F14C5AEC5B47F40F56B94C9@AM8PR07MB7476.eurprd07.prod.outlook.com> <CADVnQymOaDGhvgekUjput3s454s-7=_+_vAtRkubX82uQQB=TQ@mail.gmail.com> <F52889B5-CA1B-46AD-8C6B-26E463FCB518@apple.com> <AM8PR07MB74765135C2EDFCACBAAF5DD8B94A9@AM8PR07MB7476.eurprd07.prod.outlook.com>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <403ddc8b-c499-9d43-4b07-f34195341363@bobbriscoe.net>
Date: Thu, 06 May 2021 22:49:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <AM8PR07MB74765135C2EDFCACBAAF5DD8B94A9@AM8PR07MB7476.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------99E17AEB05744AFF7B18C5B4"
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/05GM4U-LVowLr2nxSj4g2aiZ2Eo>
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: Thu, 06 May 2021 21:49:18 -0000

Koen, eal, Vidhi,
Just checking I've understood what you intended, while I'm committing 
the proposed text to the draft. See [BB] inline...

On 18/04/2021 09:41, De Schepper, Koen (Nokia - BE/Antwerp) wrote:
>
> Ok, then we’ll take that wording and we can close this topic. Thanks both.
>
> Koen.
>
> *From:* Vidhi Goel <vidhi_goel@apple.com>
> *Sent:* Friday, April 16, 2021 11:14 PM
> *To:* Neal Cardwell <ncardwell@google.com>
> *Cc:* De Schepper, Koen (Nokia - BE/Antwerp) 
> <koen.de_schepper@nokia-bell-labs.com>; tsvwg IETF list 
> <tsvwg@ietf.org>; Christoph Paasch <cpaasch@apple.com>; Yuchung Cheng 
> <ycheng@google.com>; Praveen Balasubramanian <pravb@microsoft.com>; 
> Randall Stewart <rrs@netflix.com>; Priyaranjan Jha 
> <priyarjha@google.com>; Nandita Dukkipati <nanditad@google.com>
> *Subject:* Re: [tsvwg] Prague requirements survey
>
>     IMHO Koen's suggested alternate text for this requirement is
>     quite good. Here is a spin on Koen's text that sounds good to me
>     and explicitly mentions that RACK/RFC8985 qualifies as meeting
>     this requirement:
>
>          a scalable congestion control SHOULD be resilient to
>          reordering over an adaptive time interval that scales with
>          throughput and adapts to reordering (as in [RFC8985]), as
>          opposed to counting only in fixed units of packets (as in
>          the 3 DupACK rule of [RFC5681] and [RFC6675], which is not
>          scalable)
>
> Thanks Neal. This wording works for me.
>

[BB] I've made it clear this is in the context of loss detection, which 
otherwise isn't mentioned:

               a scalable congestion control's loss detection SHOULD be 
resilient to...

I've continued the bullet with the unchanged rationale text and the 
unchanged exception at the end, as below:

       As packet rates increase (e.g., due to new and/
       or improved technology), congestion controls that detect loss by
       counting in units of packets become more likely to incorrectly
       treat reordering events as congestion-caused loss events (see
       Appendix A.1.7 for further rationale).  This requirement does not
       apply to congestion controls that are solely used in controlled
       environments where the network introduces hardly any reordering.



Bob


>
>
>     On Apr 16, 2021, at 7:08 AM, Neal Cardwell <ncardwell@google.com
>     <mailto:ncardwell@google.com>> wrote:
>
>     On Fri, Apr 16, 2021 at 8:53 AM De Schepper, Koen (Nokia -
>     BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com
>     <mailto:koen.de_schepper@nokia-bell-labs.com>> wrote:
>
>         Hi all,
>
>         An update on the survey is available. We received an
>         additional input from Apple which we could publicly share
>         (thanks Vidhi for providing this input). I also updated the
>         consolidated view v2 (available
>         onhttps://github.com/L4STeam/l4steam.github.io#prague-requirements-compliance
>         <https://github.com/L4STeam/l4steam.github.io#prague-requirements-compliance>).
>
>         I believe it is strongly in line with the previous survey
>         conclusions as presented in last tsvwg. One main additional
>         feedback was on “7. Measuring Reordering Tolerance in Time
>         Units”. There was disagreement that using time only and not
>         packet count is a foolproof solution.As far as I understand
>         the objection is to the current wording that a time based
>         mechanism is the only/sufficient way to assure this.
>
>         The objective of this requirement is to allow a certain level
>         of reordering for L4S traffic (actually avoid delaying packets
>         in the network to guarantee correct order of packet delivery).
>         I personally could support wording that expresses the core of
>         the requirement, and not limit the text to one mechanism,
>         which would allow alternative/more robust implementations. The
>         requirement could be expressed as something like: “a scalable
>         congestion control SHOULD  be resilient to reordering over an
>         (adaptive) (time?) interval, which scales with / adapts to
>         throughput, as opposed to counting only in (fixed) units of
>         packets (as in the 3 DupACK rule of RFC 5681 TCP), which is
>         not scalable”. Let’s further discuss here on the list what
>         could be for all parties an acceptable wording.
>
>     Thanks for posting this, Koen and Vidhi.
>
>     Regarding Apple's Prague response that you posted:
>
>     https://l4steam.github.io/PragueReqs/Apple_L4S_requirements_Compliance_and_Objections.pdf
>     <https://l4steam.github.io/PragueReqs/Apple_L4S_requirements_Compliance_and_Objections.pdf>
>
>     And specifically regarding the response about a reordering
>     tolerance in time units:
>
>          Disagree that using time only and not packet count is a
>          foolproof solution. What if the time threshold value cause
>          slow recovery in case of an actual packet loss event? Would
>          it be better to use either packet count or time threshold? We
>          currently don't support RACK - so time based loss detection
>          wouldn't be possible.
>
>     I would agree that detecting losses purely based on a time
>     threshold value can cause slower recovery in case of an actual
>     packet loss event. And this can be needless delay if the path
>     actually has no reordering.
>
>     But it may be worth noting that in RACK-TLP loss detection [
>     https://tools.ietf.org/html/rfc8985
>     <https://tools.ietf.org/html/rfc8985>] if no reordering has been
>     observed on the connection then the loss detection mechanism will
>     trigger based on packet count (DupThresh=3 segments SACKed).
>     RACK-TLP only uses time-based triggering of recovery if
>     reordering has been observed on the connection. This strikes a
>     balance between quick loss recovery for paths with no reordering,
>     and reordering tolerance for paths with reordering. So in effect
>     RACK-TLP does use the approach urged above ("Would it be better
>     to use either packet count or time threshold?")
>
>     I agree it is worth clarifying in the Prague requirements whether
>     it is required that loss detection *always* be based on time
>     units, or whether it is acceptable to use an adaptive approach
>     like the RACK-TLP approach outlined above (as specified in
>     RFC8985 and implemented in Linux TCP).
>
>     IMHO Koen's suggested alternate text for this requirement is
>     quite good. Here is a spin on Koen's text that sounds good to me
>     and explicitly mentions that RACK/RFC8985 qualifies as meeting
>     this requirement:
>
>          a scalable congestion control SHOULD be resilient to
>          reordering over an adaptive time interval that scales with
>          throughput and adapts to reordering (as in [RFC8985]), as
>          opposed to counting only in fixed units of packets (as in
>          the 3 DupACK rule of [RFC5681] and [RFC6675], which is not
>          scalable)
>
>     best,
>
>     neal
>
>         Thanks,
>
>         Koen.
>
>         *From:*De Schepper, Koen (Nokia - BE/Antwerp)
>         *Sent:*Sunday, March 7, 2021 1:57 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:*Bob Briscoe <ietf@bobbriscoe.net
>         <mailto:ietf@bobbriscoe.net>>
>         *Subject:*RE: Prague requirements survey
>
>         Hi all,
>
>         The details of the consolidated view of all feedback received
>         is available and can be found via following
>         link:https://l4steam.github.io/PragueReqs/Prague_requirements_consolidated.pdf
>         <https://l4steam.github.io/PragueReqs/Prague_requirements_consolidated.pdf>
>
>         The only strong objections were against the “MUST document”
>         requirements, which will be removed from the next version of
>         the draft. Some clarifications were asked and (will be) added.
>
>         For 2 requirements a big consensus was that they should be
>         developed and evolved as needed during the experiment.
>
>         All other requirements had already implementations and if not,
>         were seen feasible/realizable and were planned to be implemented.
>
>         We will present an overview during the meeting.
>
>         Regards,
>
>         Koen.
>
>         *From:*tsvwg <tsvwg-bounces@ietf.org
>         <mailto:tsvwg-bounces@ietf.org>>*On Behalf Of*De Schepper,
>         Koen (Nokia - BE/Antwerp)
>         *Sent:*Wednesday, March 3, 2021 2:20 PM
>         *To:*tsvwg IETF list <tsvwg@ietf.org <mailto:tsvwg@ietf.org>>
>         *Subject:*Re: [tsvwg] Prague requirements survey
>
>         Hi all,
>
>         We have received several surveys privately, for which I tried
>         to get the approval for sharing those on the overview
>         page:l4steam.github.io | L4S-related experiments and companion
>         website
>         <https://l4steam.github.io/#prague-requirements-compliance>
>
>         Thanks to NVIDIA for sharing their view and feedback for their
>         GeforceNow congestion control. Their feedback was added to the
>         above overview about a week ago. As we didn’t get the explicit
>         approval for the others, we will share and present a
>         consolidated view of all feedback received later and during
>         the meeting.
>
>         Note: pdf versions are now also available on the above page
>         for easier reading.
>
>         Koen.
>
>         *From:*tsvwg <tsvwg-bounces@ietf.org
>         <mailto:tsvwg-bounces@ietf.org>>*On Behalf Of*De Schepper,
>         Koen (Nokia - BE/Antwerp)
>         *Sent:*Monday, February 8, 2021 2:37 PM
>         *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: [tsvwg] Prague requirements survey
>
>         Hi Ingemar,
>
>         Thanks for your contributions. I linked your doc to
>         thehttps://l4steam.github.io/#prague-requirements-compliance
>         <https://l4steam.github.io/#prague-requirements-compliance>web
>         page (and will do so for others).
>
>         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?
>
>         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?
>
>         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 issuesandany
>         objections/disagreements to the requirementcan 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 Briscoe                               http://bobbriscoe.net/