So, it turns out the BBRv2 team was planning on using a l4s-style/dctcp-ish ecn response. The video is up here:
https://www.youtube.com/watch?v=cJ-0Ti8ZlfE alternatively, here: http://mail.taht.net/~iccrg/IETF104-ICCRG-20190328-1610.webm The Q&A session afterward (about 28 minutes in) showed that the BBRv2 team were not even testing against fully deployed fq_codel's RFC3168 ecn response and there were all sorts of other fun questions following. So I think this answers Vint "Seersucker"' Cerf's ecn-sane's team's question "is ECN even needed for BBR?" I'm SO glad we got our SCE alternative ready for publication in time to reset the clock by a lot. The preso in tsvwg: https://www.youtube.com/watch?v=JQmWyr0JDJM&t=1h3m50s Also... Over the last week, jonathan, pete, and rodney (and jason?) also got a modified reno-style transport to respond properly to SCE: https://github.com/dtaht/bufferbloat-rfcs/tree/master/sce/results/prototype1 was the first one, the current one is even more excellent. Fun times in the congestion control universe! -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat