Re: [aqm] Minutes of the AQM WG session

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

Thank you Dave,

I'll update the minutes.

I believe the authors of DualAQM assume that all ECN traffic will have the less drastic reaction as a default (with the hope of deploying this before wide-spread use of legacy 3168 style ECN marking takes hold).

Also, thank you for your comments regarding FQ_codel and the reported linux issue (which, as you note, may be due to an incorrect config setting in the latest releases).



Regarding the identifier to differentiate legacy ECN (cc reaction on ECN per RTT = cc reaction to loss in RTT) and the differentiated response (proportional to the # of CEs per RTT) is an open question.

Perhaps we can start to gather the views of the group on this list already; There have been other uses for ECT(1) been proposed over time, and it has also been pointed out that repurposing a DiffServ Codepoint may not be the easierst to do from a procedural view.

Also, I would like to encourage members of the aqm wg to review the various versions of http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn (the technical content did change in each version substancially). Disclaimer, I'm one of the authors of that draft.

Best regards,
  Richard



> -----Original Message-----
> From: Dave Taht [mailto:[e-mail]]
> Sent: Donnerstag, 23. Juli 2015 13:24
> To: Scheffenegger, Richard
> Cc: [e-mail]
> Subject: Re: [aqm] Minutes of the AQM WG session
> 
> 1) in hard delay targets, I am credited with what matt mathis said (not
> that I disagree).
> 
> 2) In the dual queue thing I had noted that distinguishing between the two
> queues based solely on the presence of ecn capability and then using dctcp
> was non-sensical as plenty of other things like cubic would also end up
> with ecn enabled.
> 
> 3) and for the record, fq_codel as it exists today works reasonably well
> when hammered with dctcp + ecn, cubic + ecn, and and any other stuff
> without markings with the defaults. It may not give the desired reduction
> in individual queue length - and cubic vs dctcp will do badly against each
> other on a hash collision - but it is, at least, "mostly safe" were some
> sysadmin finger foo things and push dctcp (or some other non traditional
> cc) out on the world internet against fq_codel'd ecn-enabled systems.
> 
> 4) If you can't tell, it *really bothers me* when someone reports a bug in
> dctcp - at ietf - rather than through proper channels - particularly when
> it leads to evil behavior on loss, and yet I have no patches submitted nor
> means to reproduce it.  PLEASE GET A PATCH OUT to the netdev maintainers,
> it will be immediately put into the next release of linux AND backported
> to the linux stable releases.
> 
> What I see is dctcp_clamp_alpha_on_loss not defaulting to on, which based
> on the comments, should default to on. Is there somewhere else this is
> busted?
> 
> static void dctcp_state(struct sock *sk, u8 new_state)
> 
> {
> 
>         if (dctcp_clamp_alpha_on_loss && new_state == TCP_CA_Loss) {
> 
>                 struct dctcp *ca = inet_csk_ca(sk);
> 
> 
>                 /* If this extension is enabled, we clamp dctcp_alpha to
> 
>                  * max on packet loss; the motivation is that dctcp_alpha
> 
>                  * is an indicator to the extend of congestion and packet
> 
>                  * loss is an indicator of extreme congestion; setting
> 
>                  * this in practice turned out to be beneficial, and
> 
>                  * effectively assumes total congestion which reduces the
> 
>                  * window by half.
> 
>                  */
> 
> 
> 5) Missing from the preso was the actual dual queue length, just a
> comparison (cool demo tho!) - you get what queue length using curvy red?
> 
> 6) cake, of course, gets to 100s of flows without hash collisions.
> 
> 7) As I missed the tcp-prague discussion, is the proposal to reserve
> ect(1) - the former nonce bit - for dctcp? or some other diffserv or
> flowheader marking?
> 
> On Thu, Jul 23, 2015 at 8:56 AM, Scheffenegger, Richard <[e-mail]>
> wrote:
> > Hi,
> >
> > Thanks to David Schinazi for serving as the notes taker;
> >
> > I've uploaded the minutes
> > https://www.ietf.org/proceedings/93/minutes/minutes-93-aqm
> >
> > If you made a statement during the session, please review that the notes
> capture the essence of what you wanted to convey!
> >
> > Also, one name is missing (and I'm unable to replay the meetecho
> recording currently) in the minutes, if you know who made that comment
> please inform us chairs.
> >
> > Thanks,
> >   Richard (aqm chair)
> >
> > _______________________________________________
> > aqm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/aqm
> 
> 
> 
> --
> Dave Täht
> worldwide bufferbloat report:
> http://www.dslreports.com/speedtest/results/bufferbloat
> And:
> What will it take to vastly improve wifi for everyone?
> https://plus.google.com/u/0/explore/makewififast