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 <[email protected]> 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
> [email protected]
> 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
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
