Subject: [aqm] updated draft charter

From: Wesley Eddy <[email-masked]>
Date: Thu, 11 Jul 2013 00:50:19 -0400

I think the attached updated draft charter reflects most of the
feedback that we've heard so far.

Note that Dave Taht suggested we might want to go with something
like "Smarter Queue Management" (SQM) for the WG name, because
purely AQM as a name may not capture FQ type of mechanisms that we
may want to have in-scope.  I think that scoping discussion may
still be going on into Berlin, but it's a good point, and likely
some other people have cute ideas for a name that could capture
the potential broader scope.

-- 
Wes Eddy
MTI Systems

---

From: grenville armitage <[email-masked]>
Date: Thu, 11 Jul 2013 20:11:26 +1000

On 07/11/2013 14:50, Wesley Eddy wrote:
	[..]
>  I think that scoping discussion may

I don't see "SQM" adding clarity (and risks bike-shedding over
what constitutes 'Smarter...' and whether that implies scheduling
algorithms any more than 'Active..." does).

The (draft) full name "Active Queue Management and Packet Scheduling"
seems entirely reasonable, even if unpronounceable as an acronym.

(But if we're interested in alternative names: since pkt scheduling
usually implies N>1 queues, which implies classification prior
to queue-ification, perhaps the "CQS" working group instead? For
"classification, queuing and scheduling". 'Cos we might want to
also say a few words about how traffic is classified into these
actively managed and scheduled queue(s)...)

cheers,
gja

---

From: Jim Gettys <[email-masked]>
Date: Thu, 11 Jul 2013 11:47:02 -0400

> the potential broader scope.

Both Dave's and my experience as relative newcomers to this area is that
the term AQM is pretty tightly bound to mark/drop algorithms in the minds
of many people in the IETF, who also categorize other algorithms as queuing
algorithms. and make a pretty strong mental distinction between them.

As my blog post this week
http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues,
the killer combination is a cross between rapidly autotuning
mark/drop algorithms with what we're calling flow queueing (since it isn't
"fair" in the also traditional sense of TCP fair queueing at all, and may
not involve TCP flows necessarily either).

So while I'd be happy to lump this all into the AQM name bucket personally,
I do think that a name that makes clear we're considering algorithms that
may marry both lines of intellectual thought together will avoid confusion
among many who have worked in one area or the other, but not both.  "Smart
queue management" or SQM is the best we've come up with for a term.
                                                               - Jim

> --
> Wes Eddy
> MTI Systems
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>
>

---

From: [email-masked]
Date: Thu, 11 Jul 2013 17:06:53 +0100

I agreed that AQM has to some extent already been deployed in some places
and this could be confusing to then redefine or obsolete this.

For what it's worth I don't like "smart" queueing as a name - implying
it's sounds like a marketing term rather than a combination of "AQM"
mark/drop and flow scheduling.

If SQM was short for  scheduling and queue management I may have liked the
abbreviation more, ... let's see where this discussion ends.

Gorry

---

From: David Ros <[email-masked]>
Date: Thu, 11 Jul 2013 18:21:38 +0200

> and this could be confusing to then redefine or obsolete this.

+1

> mark/drop and flow scheduling.

+1

> abbreviation more, ... let's see where this discussion ends.

Since we're looking for acronyms that (a) are pronounceable, (b) do not sound like a marketing gimmick, (c) match to a WG name that conveys the essence of what the WG will do, then why not simply: QMAPS? (Queue Management And Packet Scheduling).

David

>> queue management" or SQM is the best we've come up with for a term.

=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams

---

From: Jim Gettys <[email-masked]>
Date: Thu, 11 Jul 2013 13:35:30 -0400

> > abbreviation more, ... let's see where this discussion ends.

Scheduling and Queue Management is fine with me...

>
> Since we're looking for acronyms that (a) are pronounceable, (b) do not
> sound like a marketing gimmick, (c) match to a WG name that conveys the
> essence of what the WG will do, then why not simply: QMAPS? (Queue
> Management And Packet Scheduling).
>

I'm not willing to bikeshed working group names and will live with whatever
people like.  I'm certainly not great at selecting names, having bound the
free variable with a window system name.

Names can be important: one of the problems with the "RED" algorithm,
whose initial formation was, IIRC, "Random Early Discard".  The name's
connotation implied it "randomly" discarded your packets and does so sooner
rather than later; not what most network operators want to hear. Kathie and
Van named CoDel both because "Constant Delay" describes its intended
behavior, but also because "coddling" your packets sounds warm and fuzzy,
rather than nasty and random. The great unwashed fail to understand that
packet drops can be good for their network's health...

I will not reply further to this thread.
                                           - Jim

---

From: grenville armitage <[email-masked]>
Date: Fri, 12 Jul 2013 06:00:38 +1000

[..]
>> If SQM was short for  scheduling and queue management I may have
>> liked the abbreviation more, ... let's see where this discussion
>> ends.

Like it too.

>
> Since we're looking for acronyms that (a) are pronounceable, (b) do
> not sound like a marketing gimmick, (c) match to a WG name that
> conveys the essence of what the WG will do, then why not simply:
> QMAPS? (Queue Management And Packet Scheduling).

QUEUE -- Queue Utilisation for Enhanced User Experience ?

(Thank you, I'll be here all week...)

cheers,
gja

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Jul 2013 02:56:09 +0100

1/ Name suggestion: How about just "Queue Management (QMAN)"?
Otherwise, if we coin the term smart queue mgmt, merely by proposing 
an SQM algorithm, every idiot gets to have everyone else call his/her 
algo smart.

2/ Scope: "Internet routers, lower-layer switches, other middleboxes."
Can we have host buffers in scope pls? This is the transport area, afterall.

3/ "routers, ... include buffers or queues" Buffers and queues are 
not members of the same set (IMO). I don't think this is a picky 
terminology point. Can we adopt the convention that the buffer is the 
fixed memory allocation (hardware or software), and the queue is the 
software construct within the buffer?

It already caused confusion when the problem got called bufferbloat, 
so people thought we were implying the solution was small buffers, so 
they tune out, because they rightly believe this will lead to 
unnecessarily high loss. Actually, on a high speed line with high 
in-degree, it's good practice to have a very large buffer to absorb 
bursts, as long as you have a adaptive queue threshold within it that 
rapidly clamps a tight limit on a standing queue.

Same problem in next para:
" Extremely large buffers have been noticed in some software and
   equipment.  When these queues fill, ..." ->
" Extremely large unmanaged buffers have been noticed in some software and
   equipment.  When these buffers fill, ..." ->

4/ "...proactively managing queues ..."
Picky: I think you mean reactively. Proactively maybe a bit ambitious.

5/ I suggest the enumerated bullets are changed to those below:

"The Active Queue Management and Packet Scheduling working group
   works on algorithms for proactively managing queues in
   order to:

   (1) Minimise standing queues

   (2) help flow sources control their sending rates without unnecessary
   losses, e.g. through ECN

   (3) help minimize delays for interactive applications

   (4) /consider the merits of various techniques/ to protect flows 
from negative impacts of other more
   aggressive or misbehaving flows

Reasoning:

ECN: The original text was:
"(1) help flow sources control their sending rates before the
   onset of necessary losses, e.g. through ECN"
is not accepted wisdom. What's written in RFC3168 makes sense: that 
marking for ECN traffic has to start at exactly the same point as 
loss for non-ECN traffic. Otherwise ECN traffic starves itself. 
Certainly, under v heavy load everyone has to take losses, whether 
ECN or not, but I don't think that's what you're talking about here.

Protecting flows:
The question of whether/how to recommend flow isolation or not is 
part of chartered work - the outcome shouldn't be prejudged in the charter.

6/
"  The AQM working group will publish Informational and Best Current
   Practices documents that cover the design, use, and configuration
   of algorithms for managing queues in Internet devices and software.
"
Add: The scope will include both how best to configure existing 
equipment / software as well as recommendations on designing new 
equipment / software.

7/ "  The working group will not make changes to ECN, DiffServ, or other
   IETF protocols, though existing ECN, DiffServ, and other mechanisms
   may be used within the algorithms proposed.
"
Add: The proper place for changes to ECN & Diffserv is TSVWG, but 
clearly any such changes will need to be co-ordinated with the AQM 
WG, given the code is likely to be entwined with AQM code.

8/  "Many AQM algorithms have been proposed in academic literature, but
   very few are widely implemented and deployed.  "

Is this trying to say very few types of AQM are deployed, or very few 
instances? I think it is trying to say the latter, but that just 
isn't true (IMO). WRED is very widely deployed in enterprise 
networks. And RED is implemented near-univerally by the main 
equipment vendors, and less widely deployed, but not insignificant.

9/ Gap in charter coverage?

"Merits of whether to isolate flows and if so how."

There are multiple functions that often get lumped under "AQM":
a) minimising a standing queue
b) desynchronising losses (/marks)
c) preventing large packet lock-out
d) detecting and policing flows with excessive rate
e) isolating flows from each other (e.g. SFQ)

a,b,c) can be done neutrally and imply no possible policy control.
d,e) depend on policy (which may or may not be hard-coded rather than 
configurable, e.g. all flows get equal scheduler priority).

There's been significant discussion on the list about the merits of 
different ways of doing flow isolation. This is the area where I 
think there is most latent disagreement. We have pretty good 
consensus already around the recommendations in Fred's doc. We will 
have to grasp the flow-isolation and policing nettles, so the charter 
ought to say we're going to.

For instance, my stance is that policy-related functions (d+e) should 
only be deployed at edge-policy enforcement points, not in every 
buffer. Altho SFQ clearly makes an associated AQM like CoDel work 
nicely, I preferred the direction Fred described in:
<http://www.ietf.org/mail-archive/web/aqm/current/msg00081.html>
in which there's a distinguished shared queue, then anything that 
starts causing delay in that queue gets either isolated in its own 
queue or focused policing. Rather than isolating every flow into 
separate queues from the start, because that requires prejudging the 
share of the scheduler everyone gets.

We have found that with multiple real-time video streams, they all 
have highly variable rates, so they multiplex really well together in 
a FIFO. However, if you put them through FQ or WRR, they all get 
forced into ruts that are always the wrong size for all of them. This 
isn't a problem if the sum is not often close to capacity (which is 
why SFQ can appear to be OK with multiple videos). However, the whole 
point of isolation is to protect flows when the system /is/ close to capacity.

Bob

At 18:35 11/07/2013, Jim Gettys wrote:

><<mailto:[email-masked]>[email-masked]> wrote:
>
>On 11 juil. 2013, at 18:06, 
><mailto:[email-masked]>[email-masked] wrote:
>
> >
>I'm not willing to bikeshed working group names and will live with 
>whatever people like.  I'm certainly not great at selecting names, 
>having bound the free variable with a window system name.
>
>Names can be important: one of the problems with the "RED" 
>algorithm, whose initial formation was, IIRC, "Random Early 
>Discard".  The name's connotation implied it "randomly" discarded 
>your packets and does so sooner rather than later; not what most 
>network operators want to hear. Kathie and Van named CoDel both 
>because "Constant Delay" describes its intended behavior, but also 
>because "coddling" your packets sounds warm and fuzzy, rather than 
>nasty and random. The great unwashed fail to understand that packet 
>drops can be good for their network's health...
>
> >> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy 
> <<mailto:[email-masked]>[email-masked]> wrote:
> >>
> <http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues>http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues,
> >>> <mailto:[email-masked]>[email-masked]
> >> <mailto:[email-masked]>[email-masked]
> > <mailto:[email-masked]>[email-masked]
><http://www.rennes.enst-bretagne.fr/~dros/>http://www.rennes.enst-bretagne.fr/~dros/
>
><mailto:[email-masked]>[email-masked]

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Fri, 12 Jul 2013 02:05:17 +0000

From: Bob Briscoe <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 12, 2013 9:56 AM
To: Wesley Eddy <[email-masked]<mailto:[email-masked]>>
Cc: Gorry Fairhurst <[email-masked]<mailto:[email-masked]>>, Jim Gettys <[email-masked]<mailto:[email-masked]>>, David Ros <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [aqm] updated draft charter

1/ Name suggestion: How about just "Queue Management (QMAN)"?
Otherwise, if we coin the term smart queue mgmt, merely by proposing an SQM algorithm, every idiot gets to have everyone else call his/her algo smart.

3/ "routers, ... include buffers or queues" Buffers and queues are not members of the same set (IMO). I don't think this is a picky terminology point. Can we adopt the convention that the buffer is the fixed memory allocation (hardware or software), and the queue is the software construct within the buffer?

It already caused confusion when the problem got called bufferbloat, so people thought we were implying the solution was small buffers, so they tune out, because they rightly believe this will lead to unnecessarily high loss. Actually, on a high speed line with high in-degree, it's good practice to have a very large buffer to absorb bursts, as long as you have a adaptive queue threshold within it that rapidly clamps a tight limit on a standing queue.

  (4) /consider the merits of various techniques/ to protect flows from negative impacts of other more
  aggressive or misbehaving flows

Reasoning:

ECN: The original text was:
"(1) help flow sources control their sending rates before the
  onset of necessary losses, e.g. through ECN"
is not accepted wisdom. What's written in RFC3168 makes sense: that marking for ECN traffic has to start at exactly the same point as loss for non-ECN traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy load everyone has to take losses, whether ECN or not, but I don't think that's what you're talking about here.

Protecting flows:
The question of whether/how to recommend flow isolation or not is part of chartered work - the outcome shouldn't be prejudged in the charter.

6/
"  The AQM working group will publish Informational and Best Current
  Practices documents that cover the design, use, and configuration
  of algorithms for managing queues in Internet devices and software.
"
Add: The scope will include both how best to configure existing equipment / software as well as recommendations on designing new equipment / software.

7/ "  The working group will not make changes to ECN, DiffServ, or other
  IETF protocols, though existing ECN, DiffServ, and other mechanisms
  may be used within the algorithms proposed.
"
Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly any such changes will need to be co-ordinated with the AQM WG, given the code is likely to be entwined with AQM code.

Is this trying to say very few types of AQM are deployed, or very few instances? I think it is trying to say the latter, but that just isn't true (IMO). WRED is very widely deployed in enterprise networks. And RED is implemented near-univerally by the main equipment vendors, and less widely deployed, but not insignificant.

a,b,c) can be done neutrally and imply no possible policy control.
d,e) depend on policy (which may or may not be hard-coded rather than configurable, e.g. all flows get equal scheduler priority).

There's been significant discussion on the list about the merits of different ways of doing flow isolation. This is the area where I think there is most latent disagreement. We have pretty good consensus already around the recommendations in Fred's doc. We will have to grasp the flow-isolation and policing nettles, so the charter ought to say we're going to.

For instance, my stance is that policy-related functions (d+e) should only be deployed at edge-policy enforcement points, not in every buffer. Altho SFQ clearly makes an associated AQM like CoDel work nicely, I preferred the direction Fred described in:
< http://www.ietf.org/mail-archive/web/aqm/current/msg00081.html>
in which there's a distinguished shared queue, then anything that starts causing delay in that queue gets either isolated in its own queue or focused policing. Rather than isolating every flow into separate queues from the start, because that requires prejudging the share of the scheduler everyone gets.

We have found that with multiple real-time video streams, they all have highly variable rates, so they multiplex really well together in a FIFO. However, if you put them through FQ or WRR, they all get forced into ruts that are always the wrong size for all of them. This isn't a problem if the sum is not often close to capacity (which is why SFQ can appear to be OK with multiple videos). However, the whole point of isolation is to protect flows when the system /is/ close to capacity.

>>>>> Totally Agree….

Rong

On Thu, Jul 11, 2013 at 12:21 PM, David Ros < [email-masked]<mailto:[email-masked]>> wrote:

+1

+1

I'm not willing to bikeshed working group names and will live with whatever people like.  I'm certainly not great at selecting names, having bound the free variable with a window system name.

Names can be important: one of the problems with the "RED" algorithm, whose initial formation was, IIRC, "Random Early Discard".  The name's connotation implied it "randomly" discarded your packets and does so sooner rather than later; not what most network operators want to hear. Kathie and Van named CoDel both because "Constant Delay" describes its intended behavior, but also because "coddling" your packets sounds warm and fuzzy, rather than nasty and random. The great unwashed fail to understand that packet drops can be good for their network's health...

David

>
> Gorry
>
>
>> On Thu, Jul 11, 2013 at 12:50 AM, Wesley Eddy <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/#more-1091argues ,
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
aqm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aqm

_______________________________________________
aqm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aqm

---

From: Dave Taht <[email-masked]>
Date: Thu, 11 Jul 2013 19:12:23 -0700

On Thu, Jul 11, 2013 at 6:56 PM, Bob Briscoe <[email-masked]> wrote:
> Otherwise, if we coin the term smart queue mgmt, merely by proposing an SQM
> algorithm, every idiot gets to have everyone else call his/her algo smart.

Heh. Like jim said, this is a bikeshed, and I'd like to stay out of it, too.

I note in trying to coin a new acronym, like "SQM", I'd said "smarter
queue management", not smart, (or at least I think I did) - and I
think AQM should be defined as queue length management to minimize
future confusion.

so QMAN works for me. There was another proposal earlier today(?) that
had another attempt I thought would be confusing out of context.

Feel free to bring in madison avenue.

> Can we have host buffers in scope pls? This is the transport area, afterall.

YES, PLEASE.

> 3/ "routers, ... include buffers or queues" Buffers and queues are not
> members of the same set (IMO). I don't think this is a picky terminology
> point. Can we adopt the convention that the buffer is the fixed memory
> allocation (hardware or software), and the queue is the software construct
> within the buffer?

I like it.

> It already caused confusion when the problem got called bufferbloat, so

I concur jim should have called it queue bloat, but it wasn't as
catchy as bufferbloat.

> people thought we were implying the solution was small buffers, so they tune
> out, because they rightly believe this will lead to unnecessarily high loss.
> Actually, on a high speed line with high in-degree, it's good practice to
> have a very large buffer to absorb bursts, as long as you have a adaptive
> queue threshold within it that rapidly clamps a tight limit on a standing
> queue.
>

s/buffers/queues for sure.

> Picky: I think you mean reactively. Proactively maybe a bit ambitious.

A proactive queue management algorithm SHOULD have support for tachyon
based pre-emptive feedback.

>   (2) help flow sources control their sending rates without unnecessary

I really remain dubious about usage of ECN on the world wide internet.
If deployed widely, attacks will widely use it.

> is not accepted wisdom. What's written in RFC3168 makes sense: that marking
> for ECN traffic has to start at exactly the same point as loss for non-ECN
> traffic. Otherwise ECN traffic starves itself. Certainly, under v heavy load
> everyone has to take losses, whether ECN or not, but I don't think that's
> what you're talking about here.
>
> Protecting flows:
> The question of whether/how to recommend flow isolation or not is part of
> chartered work - the outcome shouldn't be prejudged in the charter.

I'm a little vague on your intent here.

> Add: The scope will include both how best to configure existing equipment /
> software as well as recommendations on designing new equipment / software.
>
> Add: The proper place for changes to ECN & Diffserv is TSVWG, but clearly
> any such changes will need to be co-ordinated with the AQM WG, given the
> code is likely to be entwined with AQM code.

I'm not sure that this scope needs to be so limited here.

> instances? I think it is trying to say the latter, but that just isn't true
> (IMO). WRED is very widely deployed in enterprise networks. And RED is
> implemented near-univerally by the main equipment vendors, and less widely
> deployed, but not insignificant.
>
> different ways of doing flow isolation. This is the area where I think there
> is most latent disagreement.

yep.

>We have pretty good consensus already around
> the recommendations in Fred's doc. We will have to grasp the flow-isolation
> and policing nettles, so the charter ought to say we're going to.

+1.

> For instance, my stance is that policy-related functions (d+e) should only
> be deployed at edge-policy enforcement points, not in every buffer. Altho
> SFQ clearly makes an associated AQM like CoDel work nicely, I preferred the
> direction Fred described in:
> in which there's a distinguished shared queue, then anything that starts
> causing delay in that queue gets either isolated in its own queue or focused
> policing. Rather than isolating every flow into separate queues from the
> start, because that requires prejudging the share of the scheduler everyone
> gets.

Hmm.

> We have found that with multiple real-time video streams, they all have
> highly variable rates, so they multiplex really well together in a FIFO.
> However, if you put them through FQ or WRR, they all get forced into ruts
> that are always the wrong size for all of them. This isn't a problem if the
> sum is not often close to capacity (which is why SFQ can appear to be OK
> with multiple videos). However, the whole point of isolation is to protect
> flows when the system /is/ close to capacity.

Cite? Not that I disagree, I've been ramping up at looking hard at
webrtc behavior of late, just that most of my foci are focused on web,
voip, and gaming traffic on the edge to date..

> On Thu, Jul 11, 2013 at 12:21 PM, David Ros < [email-masked]>
> wrote:
>
> Names can be important: one of the problems with the "RED" algorithm, whose
> initial formation was, IIRC, "Random Early Discard".  The name's connotation
> implied it "randomly" discarded your packets and does so sooner rather than
> later; not what most network operators want to hear. Kathie and Van named
> CoDel both because "Constant Delay" describes its intended behavior, but
> also because "coddling" your packets sounds warm and fuzzy, rather than
> nasty and random. The great unwashed fail to understand that packet drops
> can be good for their network's health...
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Dave Taht <[email-masked]>
Date: Thu, 11 Jul 2013 19:24:47 -0700

> Since we're looking for acronyms that (a) are pronounceable, (b) do not sound like a marketing gimmick, (c) match to a WG name that conveys the essence of what the WG will do, then why not simply:…

I didn't go for QMAPS because MAPS is rather meaningful in another context.

Also in thinking about "QMAN", we are generally talking about
*Network* queues here, not other queues, although certainly the kinds
of issues we are addressing here have applicability to (for example)
cpu scheduling.

http://lwn.net/Articles/558603/

NQMAN doesn't exactly roll off the tongue and is hard on the eyes.
(actually the Q is rather attractive in it's own way there but I
digress)

---

From: grenville armitage <[email-masked]>
Date: Fri, 12 Jul 2013 16:10:47 +1000

On 07/12/2013 11:56, Bob Briscoe wrote:
	[..]
> software construct within the buffer?

The distinction would be an interesting one to make, but hasn't
horse bolted on this many years ago?  IMO, there's lots of history
behind the notion that a buffer is the space used to absorb
transient overloads (regardless of how implemented) and a queue
is a either a synonym for buffer or a particular subset (e.g. a
FIFO buffer).

cheers,
gja

---

From: [email-masked]
Date: Fri, 12 Jul 2013 07:43:42 +0100

I think Bob's proposal is a useful one as we move to active queue management.

 I suspect we will need to make the distinction between the two terms
every document / presentation though to make sure people see the
distinction.

Gorry

---

From: grenville armitage <[email-masked]>
Date: Fri, 12 Jul 2013 19:31:04 +1000

> every document / presentation though to make sure people see the

Conceded. Certainly worth trying if it helps clarity of understanding.
I was primarily wondering if trying to say "..the buffer is the fixed
memory allocation..." stands much chance against years of classroom
dialogue like "What does a queue do? It provides buffering....". But
I don't hold a strong opinion wrt the proposed charter wording on
this point.

cheers,
gja

-- 
Professor Grenville Armitage
Director, Centre for Advanced Internet Architectures
Faculty of Information and Communication Technologies
Swinburne University of Technology, Australia
http://caia.swin.edu.au

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 12 Jul 2013 10:41:50 -0400

> I don't hold a strong opinion wrt the proposed charter wording on

I think I agree.  This is definitely a good idea to make clear in
a "terminology" section or something in one of our WG documents, if
we then use the words consistently following that, but given that
the existing documentation in the field muddles terms, it only makes
sense for the charter to define and use them with precision, if it
makes a difference to the scoping and understanding of the work.

That said ... in the next revision, we should try to use the right
words in relevant places, but I don't think the charter is the place
we want to carve any terminology in stone.

-- 
Wes Eddy
MTI Systems

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Jul 2013 17:59:13 +0100

Dave,

One or two clarifications inline...

>I'm a little vague on your intent here.

I've suggested adding the words "consider the merits of various 
techniques" in front of "protect flows from negative impacts of other 
more aggressive or misbehaving flows"

This is a minefield, so the charter has to tread carefully, that's all.

>I'm not sure that this scope needs to be so limited here.

For ADs & chairs to discuss. I'm just trying to make the issue of WG 
demarcation explicit.

> > 9/ Gap in charter coverage?

[snip]

>voip, and gaming traffic on the edge to date..

Citations below. However, none of these papers talks about the 
problems they encountered when trying to go live with the technology. 
They had to give up because WRR in production networks completely 
unwound the 205% multiplexing efficiency they achieved between video streams.

http://www.bobbriscoe.net/projects/refb/#Weighted_andor_Proportionally_Fair:
The three under Equitable quality streaming (it wasn't even real-time 
in their case):
    * Mulroy, P., Appleby, S., Nilsson, M. & Crabtree, B., 
"<http://research.microsoft.com/en-us/um/redmond/events/pv2009/papers/session_congestion_control/Paper%2018.pdf>The 
Use of MulTCP for the Delivery of Equitable Quality Video," In: 
Proc.<http://research.microsoft.com/en-us/um/redmond/events/pv2009/default.aspx> 
Int'l Packet Video Wkshp (PV'09) IEEE (May 2009)
    * Crabtree, B., Nilsson, M., Mulroy, P. & Appleby, S., 
"<http://research.microsoft.com/en-us/um/redmond/events/pv2009/papers/session_video/paper%204.pdf>Equitable 
quality video streaming over DSL," In: Proc. 
<http://research.microsoft.com/en-us/um/redmond/events/pv2009/default.aspx>Int'l 
Packet Video Wkshp (PV'09) IEEE (May 2009)
    * Nilsson, M., Crabtree, B., Mulroy, P. & Appleby, S., "Equitable 
quality video streaming for IP networks," International Journal of 
Internet Protocol Technology 4(1):65--76 (March 2009) DOI: 
10.1504/IJIPT.2009.024171

Bob

---

From: Gorry <[email-masked]>
Date: Fri, 12 Jul 2013 19:23:49 +0100

On this point - I agree with Bob. 

I think diffserv and ECN changes really should be done in TSVWG.

Gorry

Sent from my iPad

On 12 Jul 2013, at 17:59, Bob Briscoe <[email-masked]> wrote:

> For ADs & chairs to discuss. I'm just trying to make the issue of WG demarcation explicit.

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 30 Jul 2013 11:14:06 -0400

Is there one?

Could someone at least tell us what slide we are on?

Thanks

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.