Queue Protection to Preserve Low Latency
This is an older version of an Internet-Draft whose latest revision state is "Active".
Expired & archived
|Authors||Bob Briscoe , Greg White|
|Last updated||2020-08-16 (Latest revision 2019-07-08)|
TSVART Early review (of -02) by Magnus Westerlund Ready w/issues
|IETF conflict review||conflict-review-briscoe-docsis-q-protection, conflict-review-briscoe-docsis-q-protection, conflict-review-briscoe-docsis-q-protection, conflict-review-briscoe-docsis-q-protection, conflict-review-briscoe-docsis-q-protection, conflict-review-briscoe-docsis-q-protection|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|Send notices to||Adrian Farrel <firstname.lastname@example.org>|
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
This informational document defines and explains the specification of the queue protection algorithm used in DOCSIS 3.1. It is believed this algorithm will be useful in scenarios other than DOCSIS. 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 flow(s) most likely to be responsible. It can then prevent selected packets of these flows (or whole flows) from harming the queuing delay of other traffic in the low latency queue.
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)