Re: [aqm] [tcpPrague] L4S status update

Hi Bob, A tiny correction in-line: On 11/01/16 at 12:02P, Bob Briscoe wrote: [snip] > * Data Centre TCP (DCTCP) for > o Linux (in the mainline kernel ) > o FreeBSD patch > >

Re: [aqm] [tcpPrague] L4S status update

Hi Roland + others. As regards to comments around other new congestion control algorithms and that they may need adapted dropping likelihood relation between a classic queue and L4S queue. I have not tried out but I suspect that BBR may get an unfair treatment, at the same time it is possible t

Re: [aqm] [tcpPrague] L4S status update

Hi Ingemar, my point was that it's probably better to refrain from building CC-specific behavior into network elements as the CC algorithms may evolve faster and in more flexible ways than we can foresee. Thus, it would be good to have a separation (or coupling) scheme that actually doesn't depend

Re: [aqm] [tcpPrague] L4S status update

My position remains that fq in the network opens up all possibilities for all forms of e2e congestion control. Tests with BBR vs cubic and other tcps on all the single queued aqm designs I've tried (RED, codel, pie) have been pretty dismal. Tests against fq'd with 1024 on cake and fq_codel: nary a

Re: [aqm] [tcpPrague] L4S status update

Hello Bob and Roland, I followed your discussion and want to share my opinion, here. (Comments inline). Am 22.11.2016 um 20:09 schrieb Bob Briscoe: *Is any AQM CC-neutral?** *Note rule 5 in the AQM Guidelines [RFC7567] "AQM algorithms SH

Re: [aqm] [tcpPrague] L4S status update

Jonathan, On 22/11/16 20:37, Jonathan Morton wrote: On 22 Nov, 2016, at 21:09, Bob Briscoe wrote: {Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state

Re: [aqm] [tcpPrague] L4S status update

etf.org] On Behalf Of Bless, Roland (TM) > Sent: dinsdag 22 november 2016 17:46 > To: Ingemar Johansson S ; Bob Briscoe > ; tsvwg IETF list ; TCP Prague List > ; AQM IETF list ; tcpm IETF list > > Subject: Re: [aqm] [tcpPrague] L4S status update > > Hi Ingemar, > >

Re: [aqm] [tcpPrague] L4S status update

Mario, On 24/11/16 16:57, Mario Hock wrote: Hello Bob and Roland, I followed your discussion and want to share my opinion, here. (Comments inline). Am 22.11.2016 um 20:09 schrieb Bob Briscoe: *Is any AQM CC-neutral?** *Note rule 5 in the AQM

Re: [aqm] [tcpPrague] L4S status update

> On 29 Nov, 2016, at 04:55, Matt Mathis wrote: > > Bob's point is that fq_anything forfeits any mechanism for an application or > user to imply the value of the traffic by how much congestion they are > willing to inflict on other traffic. Yes, it does. I actually consider that a good thing

Re: [aqm] [tcpPrague] L4S status update

On 28/11/16 10:42 PM, Jonathan Morton wrote: On 29 Nov, 2016, at 04:55, Matt Mathis wrote: Bob's point is that fq_anything forfeits any mechanism for an application or user to imply the value of the traffic by how much congestion they are willing to inflict on other traffic. Yes, it does. I

Re: [aqm] [tcpPrague] L4S status update

The advantages of FQ are probably more widespread than people think. * Switches tend to multiplex between ports, thus mixing up traffic naturally. * Most modern ethernet cards expose 8-64 queues - why? because this provides clear paths for multiple cpus to forward them - it's not network related

Re: [aqm] [tcpPrague] L4S status update

On 11/25/16 6:23 AM, Bob Briscoe wrote: > Jonathan, > > On 22/11/16 20:37, Jonathan Morton wrote: >>> On 22 Nov, 2016, at 21:09, Bob Briscoe wrote: >>> >>> {Note 1} I have never got a good answer to my questions on aqm@ietf as to >>> why a sqrt that controls the shrinkage of the spacing betwee