Jim,
I'm just checking we're not talking past each other. I'll repeat two
quotes from each of us, then comment.
On Thu, Dec 5, 2013 at 1:13 PM, Bob Briscoe
<<mailto:[email protected]>[email protected]> wrote:
3{New}. It SHOULD be possible to make different instances of an AQM
algorithm apply to different subsets of packets that share the same queue.
It SHOULD be possible to classify packets into these subsets at
least by ECN codepoint [RFC3168] and Diffserv codepoint [RFC2474]
(or the equivalent of these fields at lower layers),
At 19:50 05/12/2013, Jim Gettys wrote:
"Certainly, it may be the same instance of an AQM algorithm, rather
than different instances, for example."
That's true of course, but the case with one AQM handling all packets
within a queue is the norm. I want to check you're happy with the converse:
1) A set-up more like WRED which was based on Dave Clark's RIO (RED
with in and out of contract). So we can have WPIE, WCoDel etc where
the differentiation between aggregates is provided by different AQM
instances in the same queue, not by different queues with different
scheduling priorities.
2) Extending this so that AQM differentiation can be between
ECN-capable and Not-ECN-capable aggregates, not just between Diffserv
classes (an example being CoDel with a lower 'interval' for
ECN-capable packets).
I presented the evaluations of this last idea in tsvwg on the final
Friday of the Vancouver IETF - I don't think you were there.
<http://www.ietf.org/proceedings/88/slides/slides-88-tsvwg-20.pdf>
This is my primary motivation for this wordsmithing - I'm trying
allow us to move towards zero signalling delays in CoDel, PIE and RED
(currently defaults of 200ms, 100ms and 512packets respectively,
which are not good for dynamics).
Bob
At 19:50 05/12/2013, Jim Gettys wrote:
On Thu, Dec 5, 2013 at 1:13 PM, Bob Briscoe
<<mailto:[email protected]>[email protected]> wrote:
Fred, Gorry, all,
I promised to suggest text for draft-ietf-aqm-recommendation about
allowing the AQM's behaviour to be independent for ECN and non-ECN
packets. In the process, I realised we can't talk about independent
AQMs for ECN without also including Diffserv.
This gets messy, because I believe a good AQM for BE traffic with
and without ECN, should remove much if not all the need for
Diffserv. But we can't ignore Diffserv.
I agree in principle with what Bob is trying to say here (and is
very much what I've been saying in my blog entry of last summer).
Once you have things under control, the need for Diffserv diminishes
dramatically (but does not go away).
But as Bob notes, there is still a good use for Diffserv: suitably
marked traffic may want to contend for access to the channel
differently: your marked VOIP packets may want to change the
priority with which you request channel access, so that you get more
timely access to the medium. This conserves transmit opportunities,
which is often the scarcest resource in many systems (e.g. 802.11,
DOCSIS, etc.). This can be the difference between your VOIP working
well, and not working well, on a busy 802.11 network as well as
using the channel as efficiently as possible.
Similarly, if you have packets you know are background, it's helpful
to know that to ensure that they never contend for access to the
medium but will always defer to other traffic, and just scavenge
available space in other transmit opportunities where possible.
I'm a bit loathe though to tie the behavior to queues, however; in
particular, best effort traffic may want to be sent in the same
aggregate as higher (or lower) priority traffic, if there is
remaining space in the aggregate.
In short, the mental model we've had that there is a one-to-one
model of hardware and software queues (not to mention flows in a
given software queue) is often incorrect (or at least seriously
sub-optimal) in today's systems (even if the hardware queues "work"
properly, which it appears they do not in 802.11).
So I'm not sure Bob's new section 3 here is how to best to state
this (or to deal with the terminology problem). Certainly, it may
be the same instance of an AQM algorithm, rather than different
instances, for example. And "
It SHOULD be possible" is more a pious wish than anything else. But
I agree in spirit with what Bob's trying to say.
- Jim
_________________________________________________________________________________________
{In Section 4: add another bullet between recommendations 2 & 3:}
3{New}. It SHOULD be possible to make different instances of an AQM
algorithm apply to different subsets of packets that share the same queue.
It SHOULD be possible to classify packets into these subsets at
least by ECN codepoint [RFC3168] and Diffserv codepoint [RFC2474]
(or the equivalent of these fields at lower layers).
{Then a new section to expand on this before the current Section 4.3.}
4.3{New}. Independent AQM Instances for ECN and Diffserv
The recommendation to provide a separate instance of the AQM for ECN
packets goes beyond the assumptions of RFC 3168, which assumed that
only one instance of an AQM will handle both ECN-capable and
non-ECN-capable packets.
Bob
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
<mailto:[email protected]>[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
