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

From: Bob Briscoe <[email-masked]>
Date: Mon, 7 Mar 2022 22:20:03 +0000

tsvwg,

FYI, a new version of this Independent Stream draft has been submitted.
https://datatracker.ietf.org/doc/html/draft-briscoe-docsis-q-protection
More URLs in the announcement email quoted below.

Thanks go to Magnus Westerlund and David Black for their reviews, as 
well as Adrian Farrel and Eliot Lear as editors, who pitched in 
additional review comments.

Most of the following changes addressed these reviews (the remaining few 
were generated by the authors).

      Summary of changes

  * Structural changes
      o New Implementation Status section
      o Whole new subsection of Security Considerations on Resource
        Depletion Attacks
      o Increased the explanation in the 'Approach In Brief' section, so
        that it could be understood alone, without referring to the more
        detailed later Rationale sections. And structured the subsection
        on the policy parts into subsubsections on Conditions and Actions.
      o Invitation to researchers
          + Added a short 'Comments Solicited' section including
            invitation to researchers to evaluate the algo
          + Added researchers as a 4th type of target audience in the
            abstract
  * Technical changes
      o Removed redundant description of how overflow of expiry time
        might be done, now that it's done properly in the pseudocode
      o Pseudocode corrections
          + Clarified that MAX_RATE and MAX_FRAME_SIZE are resp. an
            input parameter from the rest of a DOCSIS system, and a
            global constant
          + Explained which variables are floats and which ints, which
            is nec. to understand the pseudocode
          + Fixed some pseudocode errors that would give compiler errors ;)
  * Editorial changes
      o §1. Softened assertion about self-interest
      o §1: Referenced original Low Latency DOCSIS white paper, rather
        than Internet Draft we had submitted with largely the same text,
        which has been allowed to expire.
      o Throughout: Described transform of token bucket into time units
        as a transformation, not (incorrectly) as a normalization
      o §5.5: Fixed a non-sequitur where a 'Therefore' didn't follow
        from the preceding sentence
      o Other minor improvements

Bob

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-briscoe-docsis-q-protection-03.txt
Date: 	Mon, 07 Mar 2022 05:06:22 -0800
From: 	[email-masked]
To: 	Bob Briscoe <[email-masked]>, Greg White 
<[email-masked]>, Greg White <[email-masked]>, 
[email-masked]

A new version of I-D, draft-briscoe-docsis-q-protection-03.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name: draft-briscoe-docsis-q-protection
Revision: 03
Title: The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency
Document date: 2022-03-07
Group: Individual Submission
Pages: 32
URL: 
https://www.ietf.org/archive/id/draft-briscoe-docsis-q-protection-03.txt
Status: https://datatracker.ietf.org/doc/draft-briscoe-docsis-q-protection/
Html: 
https://www.ietf.org/archive/id/draft-briscoe-docsis-q-protection-03.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-03

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 four 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; d) researchers
interested in evaluating the algorithm.

The IETF Secretariat