General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: "Dave Täht" <dave@taht.net>
To: bloat@lists.bufferbloat.net, codel@lists.bufferbloat.net
Subject: [Bloat] Fwd: [aqm] Document Action: 'On Queuing, Marking, and Dropping' to Informational RFC (draft-ietf-aqm-fq-implementation-05.txt)
Date: Wed, 6 Jan 2016 18:43:20 -0800	[thread overview]
Message-ID: <568DD0C8.3010103@taht.net> (raw)
In-Reply-To: <20160106214312.5878.251.idtracker@ietfa.amsl.com>



The IESG has approved the following document:
- 'On Queuing, Marking, and Dropping'
  (draft-ietf-aqm-fq-implementation-05.txt) as Informational RFC

This document is the product of the Active Queue Management and Packet
Scheduling Working Group.

The IESG contact persons are Spencer Dawkins and Martin Stiemerling.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-aqm-fq-implementation/




Technical Summary

This note discusses implementation strategies for coupled queuing and
mark/drop algorithms. In the discussion of Active Queue Management,
there has been discussion of the coupling of queue management
(scheduling) algorithms with mark/drop (aqm) algorithms. This note is
Informational, intended to describe reasonable possibilities without
constraining outcomes.  This is not so much about "right" or "wrong" as
it is "what might be reasonable", and discusses several possible
implementation strategies.  Also, while queuing might be implemented in
almost any layer, specifically the document addresses queues that might
be used in the Differentiated Services Architecture, and are therefore
at or below the IP layer.

Working Group Summary

This document emerged to capture some of the discussions within the WG
around the combination of scheduling and AQM mechanisms, and to clarify
the discussion, as well as providing some guidance as to how to
implement such a combination.

Document Quality

The WG is actively looking at specific combined algorithms (e.g. FQ-
Codel), which have been widely recognized as being more effective than
either algorithm alone. There exists deployed code, as well as
simulation code for this particular combination, but many other
combinations, as described in the document, of different scheduling and
queue management algorithms are possible.

Personnel

   Document Shepherd - Wesley Eddy
   Responsible Area Director - Martin Stiemerling

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm



           reply	other threads:[~2016-01-07  2:40 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20160106214312.5878.251.idtracker@ietfa.amsl.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=568DD0C8.3010103@taht.net \
    --to=dave@taht.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=codel@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox