Re: [aqm] floating a draft charter

["Scheffenegger, Richard" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
> Mirja Kuehlewind
> Sent: Donnerstag, 30. Mai 2013 14:21
> To: [e-mail]
> Cc: Wesley Eddy
> Subject: Re: [aqm] floating a draft charter
> 
> 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
> 
> 
> 
> On Monday 13 May 2013 16:39:29 Wesley Eddy wrote:
> > 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.
> 
> 
> 
> --
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Institute of Communication Networks and Computer Engineering (IKR)
> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
> 
> tel: [phone]
> email: [e-mail]
> web: www.ikr.uni-stuttgart.de
> -------------------------------------------------------------------
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm