Subject: Re: [tsvwg] New Version Notification for draft-briscoe-docsis-q-protection-02.txt

From: Bob Briscoe <[email-masked]>
Date: Mon, 31 Jan 2022 21:29:29 +0000

tsvwg,

FYI, a new version of the Independent Stream draft has been submitted.
Summary of diffs: All editorial.

Bob

On 31/01/2022 21:23, [email-masked] wrote:
> A new version of I-D, draft-briscoe-docsis-q-protection-02.txt
> has been successfully submitted by Bob Briscoe and posted to the
> IETF repository.
>
> Name:		draft-briscoe-docsis-q-protection
> Revision:	02
> Title:		The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency
> Document date:	2022-01-31
> Group:		Individual Submission
> Pages:		29
> URL:            https://www.ietf.org/archive/id/draft-briscoe-docsis-q-protection-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-briscoe-docsis-q-protection/
> Html:           https://www.ietf.org/archive/id/draft-briscoe-docsis-q-protection-02.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-briscoe-docsis-q-protection-02
>
> Abstract:
>     This informational document explains the specification of the queue
>     protection algorithm used in DOCSIS technology since version 3.1.  A
>     shared low latency queue relies on the non-queue-building behaviour
>     of every traffic flow using it.  However, some flows might not take
>     such care, either accidentally or maliciously.  If a queue is about
>     to exceed a threshold level of delay, the queue protection algorithm
>     can rapidly detect the flows most likely to be responsible.  It can
>     then prevent harm to other traffic in the low latency queue by
>     ejecting selected packets (or all packets) of these flows.  The
>     document is designed for three types of audience: a) congestion
>     control designers who need to understand how to keep on the 'good'
>     side of the algorithm; b) implementers of the algorithm who want to
>     understand it in more depth; and c) designers of algorithms with
>     similar goals, perhaps for non-DOCSIS scenarios.
>
>                                                                                    
>
>
> The IETF Secretariat
>
>

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