Subject: [aqm] floating a draft charter

From: Wesley Eddy <[email-masked]>
Date: Mon, 13 May 2013 10:39:29 -0400

Hello AQMers.  To get us a step closer to having a working
group, we'll need a charter.

I drafted the attached one, and think it's an okay starting
point.  If we can either hack on this or if someone has a
better one, I think it will be good to get done before the
Berlin meeting, since we'd like to have a WG-forming BoF.

FYI, I think we would logically adopt Fred's draft for the
first milestone.

-- 
Wes Eddy
MTI Systems

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 30 May 2013 14:20:51 +0200

Hi Wes,

thanks for writting up the chapter. The text reads really well.

I'm in favor of using AQM and ECN, but when I was asking on the mailing list, 
why ECN is not used, the main answer was it's too complex (that relates to 
AQM) and doesn't give large benefits (as operators focus on low loss rates 
and high utilization only). 

I believe the key to get AQM (and ECN) deployed is a very simple AQM scheme. 
And with simple I don't only mean simple to parametrize (like Codel) but also 
a simple and easy to understand algorithm. E.g. a step function like proposed 
with DCTCP (but higher threshold slightly below the may buffersize) to 
incentive deployment of ECN. Loss-based connections would experienced the 
same DropTail behavior than today, while ECN-enabled connections could 
benefit. If more connection support ECN in future the threshold could be 
lower. That's just a very brief idea (on deployment). 

But my point is, we should not only to standardize more and more AQM 
mechanisms because that's a large research area which maybe even should be 
homed in the IRTF, but we need to find actually deployment strategies. Having 
a working group on AQM will already help to make people aware of the topic 
and maybe think about using AQM. But only standardizing more and more AQM 
queue, might end up in investing a lot of working that no-one will ever use.

Mirja

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 30 May 2013 14:59:25 +0000

The (operational) difficulty with a simple step-function ECN marking would be that it treats non-ECN, and ECN flows differently, depending on the reaction to that signal. As soon as a mix of ECN and non-ECN reaches the threshold, all non-ECN packets would  be dropped, but ECN would be marked (until Drop-Tail of the queue has to happen when it runs full). Thus ECN would push out non-ECN.

Of course, for a DCTCP like sender/receiver with a gradual reaction (possibly even a per-segment congestion control reaction in the form of pacing or cwnd adjustment), that would be a big incentive.

Another question I have - from the control loop perspective, it would be preferential to mark/drop at the head of the queue (at dequeue) rather at enqueue, which delays the signal (ECN or loss) by the queuing delay. What is the main obstacle, that this approach is rapidly dismissed, other than the "wasted" cycles keeping a segment, that may be marked/dropped later, in the queue. Are there implementation difficulties that basically rule out such a strategy to minimize the delay of the congestion signal to the end hosts? Or would (somehow) the drop of a segment of a different flow, which wasn't actually the one that eventually overloads the queue, lead to unfairness between flows or synchronization effects?

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mirja Kuehlewind
> Sent: Donnerstag, 30. Mai 2013 14:21
> To: [email-masked]
> Cc: Wesley Eddy
> Subject: Re: [aqm] floating a draft charter
> 
> Hi Wes,
> 
> I'm in favor of using AQM and ECN, but when I was asking on the mailing
> list, why ECN is not used, the main answer was it's too complex (that
> relates to
> And with simple I don't only mean simple to parametrize (like Codel) but
> also a simple and easy to understand algorithm. E.g. a step function like
> proposed with DCTCP (but higher threshold slightly below the may
> buffersize) to incentive deployment of ECN. Loss-based connections would
> experienced the same DropTail behavior than today, while ECN-enabled
> connections could benefit. If more connection support ECN in future the
> threshold could be lower. That's just a very brief idea (on deployment).
> 
> homed in the IRTF, but we need to find actually deployment strategies.
> Having a working group on AQM will already help to make people aware of
> the topic and maybe think about using AQM. But only standardizing more and
> more AQM queue, might end up in investing a lot of working that no-one
> will ever use.
> 
> Mirja
> 
> 
> 
> > Hello AQMers.  To get us a step closer to having a working group,
> > we'll need a charter.
> >
> > I drafted the attached one, and think it's an okay starting point.  If
> > we can either hack on this or if someone has a better one, I think it
> > will be good to get done before the Berlin meeting, since we'd like to
> > have a WG-forming BoF.
> >
> > FYI, I think we would logically adopt Fred's draft for the first
> > milestone.
> 
> 
> 
> --
> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
> 
> tel: +49(0)711/685-67973
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 30 May 2013 12:13:41 -0400

> queue, might end up in investing a lot of working that no-one will ever use.

I suggest appending something like this to the charter:

  Many AQM algorithms have been proposed in academic literature, but
  very few are widely implemented and deployed.  A goal of the working
  group is to produce recommendations that will actually be used, and
  algorithms that will actually be implemented, deployed in equipment,
  and enabled.  Towards these ends, the group actively encourages
  participation from operators and implementers, and will coordinate
  with the IETF OPS area and other relevant parts of the IETF and
  Internet community.  Wider research and evaluation of AQM mechanisms
  shall be coordinated with the IRTF/ICCRG, and significant
  participation in this WG from the academic and research community is
  highly desirable, when it is directly relevant to implementation and
  deployment.

We will definitely need to get engagement from some of the operators
that participate in the IETF, and should solicit participation more
widely outside as well (e.g. advertise to NANOG list, bufferbloat
list, etc.) in order to attract operators and implementers that aren't
already aware of this activity.

Would this help to address your concern?

-- 
Wes Eddy
MTI Systems

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 30 May 2013 09:16:51 -0700

>   very few are widely implemented and deployed.  A goal of the working
I would suggest changing "A goal" to "the goal"