[03:00:08] zulipbot joins the room
[04:22:32] alex-meetecho joins the room
[04:40:44] Christian Huitema joins the room
[04:49:28] Meetecho joins the room
[04:50:50] Ayush Mishra joins the room
[04:50:50] Paolo Saviano joins the room
[04:51:04] Praveen Balasubramanian joins the room
[04:51:28] Wu Zhao joins the room
[04:51:30] Yoshifumi Nishida joins the room
[04:51:44] Jonathan Morton joins the room
[04:51:58] Jana Iyengar joins the room
[04:52:17] Hirochika Asai joins the room
[04:52:27] Geoff Huston joins the room
[04:52:31] Christian Huitema_858 joins the room
[04:52:38] Richard Scheffenegger joins the room
[04:52:40] Paolo Saviano leaves the room
[04:52:43] Richard Scheffenegger leaves the room
[04:52:46] Richard Scheffenegger joins the room
[04:53:07] Paolo Saviano joins the room
[04:53:39] Peter Heist joins the room
[04:53:53] Mihail Yanev joins the room
[04:54:10] Bob Briscoe joins the room
[04:54:15] Kazuho Oku joins the room
[04:54:17] Dmitri Tikhonov joins the room
[04:54:18] Gorry Fairhurst joins the room
[04:54:19] Christian Hopps joins the room
[04:54:30] David Black joins the room
[04:54:43] Nicolas Kuhn joins the room
[04:55:49] Alessandro Ghedini joins the room
[04:55:50] Oshani Dayaratna joins the room
[04:56:04] Greg White joins the room
[04:56:07] Spencer Dawkins joins the room
[04:56:35] John Border joins the room
[04:56:42] Michael Scharf joins the room
[04:57:01] spencerdawkins joins the room
[04:57:06] Szilveszter Nadas joins the room
[04:57:14] <Christian Huitema_858> Is this chat working?
[04:57:21] Wesley Eddy joins the room
[04:57:37] <Kazuho Oku> Christian: I see you
[04:57:44] <Praveen Balasubramanian> yes
[04:57:44] <Jonathan Morton> apparently so
[04:58:02] Colin Perkins joins the room
[04:58:08] 木村 大和 joins the room
[04:58:24] Chi-Jiun Su joins the room
[04:58:30] Neal Cardwell joins the room
[04:58:56] Rohit Abhishek joins the room
[04:58:57] Gabriel Montenegro joins the room
[04:58:58] <Bob Briscoe> I'm not sure :|
[04:59:03] Jörg Deutschmann joins the room
[04:59:04] Anna Brunstrom joins the room
[04:59:14] Kiran Makhijani joins the room
[04:59:26] Balazs Varga joins the room
[04:59:31] Stuart Cheshire joins the room
[04:59:34] Kazuaki Ueda joins the room
[04:59:41] Marten Seemann joins the room
[04:59:44] Philip Eardley joins the room
[04:59:47] Juhamatti Kuusisaari joins the room
[04:59:51] Dirk Hugo joins the room
[04:59:51] Lars Eggert joins the room
[04:59:54] Brian Trammell joins the room
[04:59:56] Steffen Klassert joins the room
[05:00:18] <Jana Iyengar> Can you hear me?
[05:00:22] <Bob Briscoe> Yup
[05:00:24] Luke Curley joins the room
[05:00:31] Joakim Misund joins the room
[05:00:41] Lv Yunping joins the room
[05:00:55] <Wu Zhao> Yep
[05:00:59] Koen Schepper joins the room
[05:00:59] <Wu Zhao> I can hear you.
[05:01:16] Junyu Lai joins the room
[05:01:19] <Jana Iyengar> Who wants to do minutes?
[05:01:34] Ingemar Johansson joins the room
[05:01:44] <Jonathan Morton> *crickets*
[05:01:48] Yanmei Liu joins the room
[05:01:53] John Kaippallimalil joins the room
[05:01:55] <Brian Trammell> i'm doubling sessions this morning
[05:01:56] Markus Amend joins the room
[05:02:00] <Wesley Eddy> I'll do it
[05:02:00] <Brian Trammell> but I'll volunteer
[05:02:01] Kevin Yang joins the room
[05:02:04] <Brian Trammell> if I can have a backup
[05:02:17] <Brian Trammell> okay, wes and me. hi wes!
[05:02:24] Mirja Kühlewind joins the room
[05:02:24] Carsten Bormann joins the room
[05:02:46] Philip Eardley leaves the room
[05:02:47] Igor Gashinsky joins the room
[05:02:51] Philip Eardley joins the room
[05:02:55] Philipp Tiesel joins the room
[05:02:59] Frode Kileng joins the room
[05:03:23] Bhavit Shah joins the room
[05:03:36] Eric Kinnear joins the room
[05:04:00] Igor Lubashev joins the room
[05:04:59] Zhuangyan joins the room
[05:04:59] <Colin Perkins> “Beyond Jain’s Fairness Index: Setting the Bar For The Deployment of Congestion Control Algorithms”
[05:05:19] Nitin Batta joins the room
[05:05:37] Luis Contreras joins the room
[05:05:51] Ian Swett joins the room
[05:05:53] Dirk Hugo leaves the room
[05:06:23] Andrew McGregor joins the room
[05:06:36] Nick Banks joins the room
[05:07:45] Yuchung Cheng joins the room
[05:08:34] Lohith Bellad joins the room
[05:09:11] Dirk Hugo joins the room
[05:09:11] Vidhi Goel joins the room
[05:12:03] <Ingemar Johansson> I recall an old paper that experimented with this to solve buffer bloat problems in 3G, I believe?
[05:12:38] Yuchung Cheng leaves the room
[05:12:41] Yuchung Cheng joins the room
[05:12:59] Yuchung Cheng leaves the room
[05:13:02] Yuchung Cheng joins the room
[05:13:12] <Ingemar Johansson> This work seems to be more detailed though
[05:13:40] englishm joins the room
[05:14:16] Lucas Pardue joins the room
[05:14:32] Mike English joins the room
[05:15:13] Dirk Hugo leaves the room
[05:15:39] Uma Chunduri joins the room
[05:15:53] Dirk Hugo joins the room
[05:15:56] Dirk Hugo leaves the room
[05:15:58] Dirk Hugo joins the room
[05:16:27] Ruediger Geib joins the room
[05:18:06] ihlar joins the room
[05:19:01] Dirk Hugo leaves the room
[05:19:07] Dirk Hugo joins the room
[05:20:00] Hajime Fujita joins the room
[05:20:03] Bhavit Shah leaves the room
[05:20:09] Bhavit Shah joins the room
[05:20:17] frodek joins the room
[05:21:08] <Ingemar Johansson> It could be this ? https://www.researchgate.net/publication/288856361_DRWA_A_Receiver-Centric_Solution_to_Bufferbloat_in_Cellular_Networks
[05:21:56] <Christian Huitema_858> In quic you could apply this algorithm per stream, e.g., background stream in long connection.
[05:22:11] Marcus Ihlar joins the room
[05:22:48] Junyu Lai leaves the room
[05:23:02] Szilveszter Nadas leaves the room
[05:23:06] Szilveszter Nadas joins the room
[05:25:24] Jake Holland joins the room
[05:25:35] Loren McIntyre joins the room
[05:25:57] <Christian Huitema_858> Vidhi, you should use a headset!
[05:26:00] Markku Kojo joins the room
[05:26:37] <Christian Hopps> headset +1
[05:27:31] <Jonathan Morton> or at least a microphone with decent echo cancellation
[05:27:48] Mihail Zverev joins the room
[05:27:55] <Nicolas Kuhn> Agree on the trend for reduced buffer occupation - the questions on the interaction with AQM applies also
[05:28:07] <Carsten Bormann> (the echo cancellation is in the OS, these days)
[05:28:16] <Ingemar Johansson> +1
[05:28:36] <Mihail Yanev> given 50 ms and 100Mbps 1250 is about 2.5xBDB
[05:28:38] <Christian Hopps> Does echo cancellation really work when you have people all over the world though?
[05:29:22] <Jonathan Morton> echo cancellation only needs to refer to what comes out of the local speakers
[05:29:25] <Carsten Bormann> Christian: The echo cancellation is local.  The OS minimizes the feedback coming from its playout.
[05:29:26] <Ian Swett> I'm trying to understand if this is a transport level problem or an HTTP problem.  If it's only HTTP, then I think mapping the lowest HTTP priority to a best effort congestion controller largely mitigates this issue.
[05:29:27] <Jana Iyengar> @Christian: You can't do that without splitting out the CC per stream (or stream bundle)... that is complicated because you then need RTT measurements per stream, etcc.
[05:29:33] <Christian Hopps> ah right, that makes sense. :)
[05:30:36] <Christian Huitema_858> If you do that on the receive side, you can use rLEDBAT to drive the per-stream flow control.
[05:31:05] <Brian Trammell> Eric, do you have some data you could share with Praveen (perhaps parameters that could be used to simulate traffic?)
[05:31:23] <Brian Trammell> the diversity of vantage points you have is... interesting :)
[05:31:35] Nicolas Kuhn leaves the room
[05:32:23] <Brian Trammell> hi Ayush
[05:32:29] <Brian Trammell> we are not *that* scary :)
[05:32:32] <Jonathan Morton> o7
[05:33:05] <Eric Kinnear> Brian: Potentially? I've got a couple of pcaps showing some of this recently, but it was part of an issue with a carrier and some of our favorite middlebox vendors which probably aren't as share-able. Worst case we could probably stand up an endpoint configured similarly for testing. Praveen, would be happy to sync up offline for that if you're interested in running some tests. :)
[05:33:11] <Ian Swett> To be clear, I'm not talking about multiple congestion controllers operating a the same time, more switching to a BE CC when all content remaining is the lowest priority.
[05:33:16] Nicolas Kuhn joins the room
[05:33:35] <Jana Iyengar> +1 Ian - makes sense
[05:33:56] <Brian Trammell> hey look, interesting behavior from a middlebox we can't easily talk about, who would have thought ;)
[05:33:58] <Jana Iyengar> You do run the risk of having to switch back when there's other content
[05:34:48] <Ian Swett> Agreed, which means it means they need to share state.  Which in Linux, I believe is already true.
[05:35:08] <Ian Swett> QUIC is not quite there
[05:35:27] <Ian Swett> (our QUIC impl)
[05:36:10] Ruediger Geib leaves the room
[05:37:34] <Szilveszter Nadas> I have voice quality issues for all speakers, voice is sparkling. Is there a well known method to fix?  It does not look a connection issue, as the video is smooth.
[05:37:53] <Carsten Bormann> Platform
[05:37:53] <Ian Swett> My audio is smooth
[05:37:58] Dragana Damjanovic joins the room
[05:37:59] <Carsten Bormann> Platform?
[05:38:00] <Meetecho> Szilveszter Nadas: what browser are you using?
[05:38:03] <Praveen Balasubramanian> Ian that's certainly an interesting idea for when different priority resources are fetched using the same transport connection
[05:38:06] <Szilveszter Nadas> Firefiox
[05:38:14] <Jonathan Morton> you might be clipping - turn down soundcard volume, turn up analogue amplifier
[05:38:16] <Praveen Balasubramanian> Eric thanks, I will reach out offline
[05:38:49] <Ingemar Johansson> Good audio here, a bit boomy but otherwise fine
[05:38:53] <Carsten Bormann> Szilvester: On what platform?
[05:38:59] <Szilveszter Nadas> win 10
[05:39:21] <Brian Trammell> audio here is also basically perfect
[05:39:26] <Carsten Bormann> Here, too
[05:39:29] <Ingemar Johansson> Try the good old way... try and reboot :-|
[05:39:38] <Lucas Pardue> Ian, seems like an opportunity for a multipath QUIC, with different CC per path, to do stream traffic steering based on priority ;)
[05:39:42] <Ian Swett> Praveeen: Happy to chat afterwards, though the idea is quite simple.
[05:39:59] <Carsten Bormann> reboot is what I would have recommended on a mac
[05:40:16] <Jana Iyengar> @Christian: Ah, ok, for some reason I assumed you were talking about LEDBAT++. Yeah, that's an interesting idea...
[05:40:46] <Meetecho> Szilveszter Nadas: you can also try just reconnecting the audio, if you didn't try already (circling arrows in bottom right)
[05:40:48] <Ian Swett> @Lucas let's not make things overly complex.
[05:41:10] <Christian Huitema_858> @jana: :-)
[05:41:35] <Jonathan Morton> that's quite good classification accuracy
[05:41:46] <Jana Iyengar> @Ian: The main thing to manage there will be transitioning a connection from LEDBAT++ to others and back. You could save and restore state, but otherwise, seems reasonable.
[05:41:50] <Brian Trammell> ...i'm pretty sure Lucas was joking, but he's actually not wrong...
[05:41:56] <Vidhi Goel> @Praveen: when does the single slowdown happen on rLEDBAT? After slow start?
[05:42:20] <Jana Iyengar> @Brian @Lucas: Say Multipath one more time.
[05:42:28] <Brian Trammell> technically didn't say it
[05:42:33] <Ian Swett> @Jana we do that for BBRv1 and v2, so I think it could be done more widely.
[05:42:44] <Szilveszter Nadas> Meetecho: did that. Looks like it was an issue with my headphones. Went from Bluetooth to wire. Strangely it worked well for music.
[05:42:46] <Ingemar Johansson> What would be interesting is to know to which extent HyStart is turned off with Cubic
[05:43:12] <Nicolas Kuhn> +1 on Hystart
[05:43:41] <Jonathan Morton> @szilvester: it could be the sample rate is different for voice versus music, and bluetooth might be sensitive to that
[05:43:43] <Jana Iyengar> 17.67% unknown.
[05:44:03] <Jana Iyengar> That's BBRv1, I think, since this is from late 2019
[05:44:19] <Ingemar Johansson> Possible
[05:44:29] <Lucas Pardue> remember that there are H3 control streams that will be active and you might not want those scavenging
[05:44:59] <Praveen Balasubramanian> @Vidhi right after initial slow start exit, then every 60 seconds
[05:44:59] <Brian Trammell> will just say that the prospect of a bandwidth-oriented and a background "stream" between the same two endpoints is quite interesting (also outside the H3 context)
[05:45:20] <Jana Iyengar> "BBR overtakes Cubic" (in more ways than one)
[05:46:08] <Christian Huitema_858> That's a good thing. BBR is finally fighting Cubic's buffer bloat
[05:46:16] <Wu Zhao> Has Netflix switched to BBR already now?
[05:47:05] Chunshan Xiong joins the room
[05:48:12] <Vidhi Goel> @Praveen thanks. So rLEDBAT uses a fixed interval (of 60s) instead of 9 times the cwnd growth duration
[05:48:24] Chunshan Xiong leaves the room
[05:48:29] Chunshan Xiong joins the room
[05:49:07] <Praveen Balasubramanian> @Vidhi, yes, but that's just temporarily to simplify the implementation. we would like do the proper algorithm eventually
[05:49:29] <Ingemar Johansson> Akamai CC, is it a modified BBR ?
[05:49:37] Hajime Fujita leaves the room
[05:49:37] <frodek> Interesting to know what the big CDNs are using. AFAIK AWS switched to BBR in the spring 2019. What about CloudFlare?
[05:49:39] Hajime Fujita joins the room
[05:50:04] <Lohith Bellad> Cloudflare uses BBR
[05:50:11] <frodek> thx Lohith
[05:51:23] Hajime Fujita leaves the room
[05:51:26] Hajime Fujita joins the room
[05:51:41] <Ingemar Johansson> So the outcome is that HyStart on or off in Cubic is a quite uninteresting question in a few years from now ? :-)
[05:52:20] <Christian Huitema_858> My QUIC implementation adds Hystart to BBR...
[05:52:28] Yunfei Ma joins the room
[05:53:18] <Ingemar Johansson> OK. Not HyStart++ ?
[05:53:31] <Christian Huitema_858> Yes, ++
[05:53:39] <Vidhi Goel> @Praveen ok. I will try to follow ledbat++ for rledbat until I can't. :-)
[05:53:52] <Peter Heist> very interesting work Ayush :)
[05:53:59] <Christian Huitema_858> You can implement ++ by shortening the BBR testing cycle
[05:54:12] Kazuho Oku leaves the room
[05:54:15] Kazuho Oku joins the room
[05:54:18] Kazuho Oku leaves the room
[05:54:21] Kazuho Oku joins the room
[05:54:24] <Ingemar Johansson> OK, we have seen quite a few issues with HyStart in cellular, overly sensitive to scheduling jitter, DRX,
[05:54:26] <Ian Swett> Thanks for the research, this is very interesting
[05:54:41] <Ingemar Johansson> HyStart++ is likely better off
[05:54:48] <Jana Iyengar> +1 Yuchung
[05:56:35] <Jana Iyengar> BBRv2 = noise? That might be a cool unintentional property :-)
[05:56:56] <Christian Huitema_858> @Ingemar: yes you need to deal with jitter. See https://huitema.wordpress.com/2019/11/11/implementing-cubic-congestion-control-in-quic/
[05:57:55] 木村 大和 leaves the room
[05:58:20] <Gorry Fairhurst> Interesting talk! - Would be nice to see this talk again (with new data), if the measurements continue!!!
[05:58:49] Zhen Cao joins the room
[05:59:33] <Lohith Bellad> +1 Gorry
[06:00:44] Eckard Bogenfeld joins the room
[06:00:49] <Ingemar Johansson> @Christian, thanks for the link
[06:02:36] <Ayush Mishra> @all thanks for the comments!
[06:03:48] Zhibo Hu joins the room
[06:04:20] <Ayush Mishra> @Jana - to be fair we tested BBRv2 when it was in its initial stages. And I probably misspoke when I said it was noise - the main problem we were having was getting consistent cwnd responses from BBRv2
[06:06:21] <Jana Iyengar> @Ayush: Thanks for clarifying. I expected it might have been because of the evolving form of BBRv2. I found it interesting that you did find a BBRvG1.1 though
[06:06:28] Randy Bush joins the room
[06:06:40] Randy Bush leaves the room
[06:06:50] Randy Bush joins the room
[06:07:07] Gabriel Montenegro leaves the room
[06:07:44] <Ayush Mishra> We have comparisons for BBRv1, BBR G1.1 and BBRv2 graphs in the paper :) (which can be found here: https://www.comp.nus.edu.sg/~ayush/images/sigmetrics2020-gordon.pdf)
[06:09:22] Uma Chunduri leaves the room
[06:10:56] <Christian Hopps> The common intel 10G NICs don't provide HW timestamps unfortunately. :(
[06:13:23] <Mirja Kühlewind> this is ledbat's decrease function: https://tools.ietf.org/html/rfc6817#section-2.4.2
[06:14:19] <Praveen Balasubramanian> right this is effectively ledbat and ledbat++ MD
[06:14:34] <Jana Iyengar> +1 Praveen Mirja
[06:14:44] <Jana Iyengar> Does this turn BBR into a window-based sender?
[06:15:00] Zhibo Hu leaves the room
[06:15:17] Jiao Kang joins the room
[06:15:39] Zongpeng Du joins the room
[06:18:10] <Praveen Balasubramanian> I am quite surprised that delay based does better than accurate ECN
[06:18:43] <Ayush Mishra> I guess that's down to ECN being a very coarse congestion signal
[06:18:53] <Christian Huitema_858> @praveen -- need independent repro...
[06:18:55] <Jana Iyengar> Why? If the delay measurements are accurate and they accurately reflect queue-size, it's infinite granularity
[06:18:58] <Praveen Balasubramanian> this was DCTCP, which is fine grained
[06:19:03] <Yuchung Cheng> The real magic is accurate measurement of network queue with an oracle target given. DCTCP has to probe.
[06:19:06] <Jonathan Morton> it's related to the very crude AQM typically used with DCTCP
[06:19:23] <Jonathan Morton> a hard queue depth threshold function
[06:19:49] <Jonathan Morton> we did some tests with the help of HPE, using a queue depth proportional ramp marking
[06:20:08] <Jonathan Morton> the results were much better than DCTCP, with a similar type of response
[06:20:19] <Vidhi Goel> +1 Jana
[06:20:56] <Ingemar Johansson> I believe the Prague presentation gives some input
[06:21:14] Quang-Huy Nguyen joins the room
[06:21:27] <Bob Briscoe> @Jonathan, yes Joakim has done extensive comparisons of step v ramp. It's better. Not sure I'd say it's /much/ better. But I guess it depends on the definition of 'much'.
[06:21:44] <Jonathan Morton> so we essentially used an explicit signal of queue depth, rather than measuring it at the endpoints
[06:21:45] <Bob Briscoe> However, I'd still recommend ramp over stap
[06:23:14] <Gorry Fairhurst> @BobB: "stap"?
[06:23:46] Szilveszter Nadas leaves the room
[06:23:51] Szilveszter Nadas joins the room
[06:23:52] <Carsten Bormann> (step + stab)/2
[06:24:08] <Ingemar Johansson> Yet another of Bob's inventions :-)
[06:25:10] Anna Brunstrom leaves the room
[06:25:13] Anna Brunstrom joins the room
[06:25:29] Vidhi Goel leaves the room
[06:25:34] Vidhi Goel joins the room
[06:25:52] Nicolas Kuhn leaves the room
[06:26:23] Dmitriy Moskvitin joins the room
[06:26:29] Nicolas Kuhn joins the room
[06:26:53] Kazuho Oku leaves the room
[06:27:00] Kazuho Oku joins the room
[06:27:08] Zongpeng Du leaves the room
[06:27:20] Zongpeng Du joins the room
[06:27:30] Kazuho Oku leaves the room
[06:27:35] Kazuho Oku joins the room
[06:30:26] Zongpeng Du leaves the room
[06:32:07] <Vidhi Goel> Reg. BBRv2, without delay feedback, it is pretty tricky to choose BBRv2 over CUBIC. It would be interesting to see how the AccECN could help with some delay signaling.
[06:33:51] Zongpeng Du joins the room
[06:34:16] Oshani Dayaratna leaves the room
[06:36:10] Kevin Yang leaves the room
[06:36:22] <Christian Huitema_858> Why should CC algorithms be fair with the legacy CC that need large queue and cause large delay?
[06:37:09] <Jana Iyengar> +1 Christian.
[06:38:06] <Spencer Dawkins> @Christian, is this about how quickly legacy CC can go away? (years vs decades)?
[06:38:40] <Jana Iyengar> Stomping on bad legacy CC is not a bad idea :-)
[06:38:50] <Vidhi Goel> :-)
[06:38:52] <Christian Huitema_858> +1 jana
[06:38:55] <Lucas Pardue> reminds me of Hotnets https://dl.acm.org/doi/10.1145/3422604.3425939
[06:38:56] Ian Swett leaves the room
[06:39:01] <Vidhi Goel> Did we already sharehttps://www.cs.cmu.edu/~rware/assets/pdf/ware-hotnets19.pdf
[06:39:05] <Jonathan Morton> except that it hurts all the existing trffic
[06:39:14] <Ayush Mishra> Good luck to 30% of the Internet
[06:40:01] <Jonathan Morton> data volume != utility
[06:40:11] <Gorry Fairhurst> -1 Jana ...that is controversial ... but so is the opposite... we need some way for legacvy to "survive" but that might not need to be "fair" - equality isn't a goal.
[06:40:13] <Spencer Dawkins> @Jonathan, that's why I asked about years vs decades. Christian made the point about user-space CC being more agile, maybe 18 months ago?
[06:40:26] <Praveen Balasubramanian> right cubic is very widespread, probably almost just exclusive on billions of end devices . we almost always talk about server to client but upload data is also going up
[06:40:28] <Colin Perkins> @Vidhi that's one of the ANRP talks later today
[06:40:55] <Vidhi Goel> cool
[06:41:06] <Jonathan Morton> yes, I recommend everyone here attends the IRTF opening session later today
[06:41:11] <Jana Iyengar> @Gorry, I think we need more forcing functions for legacy endpoints to upgrade.
[06:41:18] <Ayush Mishra> While it might not make sense to kill ourselves to be fair to legacy TCP, I think a smooth transition from traditional TCP to newer TCP variants is in everyone's interest
[06:41:34] <Christian Hopps> What about challenged communities who might not be able to upgrade things so easily?
[06:41:57] <Ayush Mishra> +1 Praveen
[06:41:58] <Praveen Balasubramanian> +1 Ayush, incremental deployment is an important consideration
[06:41:59] <Spencer Dawkins> I haven't seen a post about "386es in closets still sending mail decades later" in about 24 hours ...
[06:42:05] <Christian Hopps> :)
[06:42:10] <Christian Hopps> Just thinking out loud
[06:42:25] <Peter Heist> +1 Christian
[06:42:41] <Spencer Dawkins> @Christian Hopps, that's why I asked about how long we wait to assume that people can be using user-space CC.
[06:42:46] <Jana Iyengar> I am always intrigued by such challenged communities. This argument surely wouldn't hold for security vulnerabilities. Why do we think this is reasonable for poor CC?
[06:43:00] <Jonathan Morton> awful lot of 200MHz MIPS based CPE floating around with no firmware upgrade path
[06:43:33] <Christian Hopps> @jana who says things are upgraded for security vuln either? :)
[06:43:42] <Gorry Fairhurst> @Jana - would be fun/useful/insightful to continue this ... but not within this thread at the moment.
[06:43:57] <Jonathan Morton> awful lot of big companies still using MS Office 2003 for current projects, apparently
[06:44:11] <Spencer Dawkins> @Jana - I think the point of SUIT and TEEP was that a lot of IoT devices were "sucks to be you" on upgrades :-(
[06:44:12] <Lucas Pardue> internet of&nbsp;CChit
[06:44:21] <Jonathan Morton> don't overestimate the speed of getting rid of all legacy stuff
[06:44:49] <Ayush Mishra> Also, I think a CC being poor or not is highly contextual. traditional CC might still work well in certain scenarios
[06:44:58] Kazuho Oku leaves the room
[06:45:02] <Christian Hopps> As a newbie in this space, the earlier comment about perhaps not being fair as long as you don't kill the legacy stuff seems a good compromise.
[06:45:05] Kazuho Oku joins the room
[06:45:25] <Ayush Mishra> +1 Jonathan, Christian
[06:45:28] <Jonathan Morton> NewReno has the vitue of being really simple to implement in constrained hardware, like IoT
[06:45:49] <Kazuho Oku> Are new CC really stomping on existing devices using older CCAs, when the bandwidth grows every year?
[06:46:07] <Spencer Dawkins> @Jonathan, understood.
[06:46:25] Dmitriy Moskvitin leaves the room
[06:46:30] <Ingemar Johansson> But you are not so likely to run high speed XR applications on constrained IoT or?
[06:46:31] <Carsten Bormann> Over in LWIG we are encouraging constrained devices to pick up TCP, maybe we should wait for CC to settle?
[06:46:49] <Ayush Mishra> @Kazuho Our results show that it really depends on what your network looks like (bandwidth, RTT, buffer size). It's all contextual
[06:46:58] <Vidhi Goel> By old CCA, is everyone just pointing to NewReno or are there others?
[06:46:58] <Brian Trammell> would anyone here object to copying the Jabber logs into the raw minutes notes? the side discussion here is useful and also seems like it should be part of the record.
[06:47:03] <Ingemar Johansson> And the congestion window is likely just a few segments in constrained IoT
[06:47:17] <Brian Trammell> (jabber is note well of course, but checking anyway)
[06:47:21] <Praveen Balasubramanian> @Carsten CC will not "settle" any time soon :)
[06:47:21] <Christian Hopps> When I worked on Terastream our goal was to deliver isolated 1G sym from the user to the CDN, so no congestion until the server :)
[06:47:25] <Spencer Dawkins> @Brian, I wish we all did that ...
[06:47:45] <Yuchung Cheng> Karzuho raised a great question I couldn't find an answer. What problems in real world applications are caused by TCP unfairness? all the results are based on lab testing not production real networks with real applications. Would love to learn any good studies in this space.
[06:48:18] <Ayush Mishra> + Yuchung
[06:49:03] <Praveen Balasubramanian> the closest approximation I can think of for the lab test is two users both copying large files sharing the bottleneck
[06:49:03] <Christian Huitema_858> I remember people queuing at the Mike in Montreal to tell me that my concerns were unfounded, the network was robust, what the hosts implemented did not matter so much...
[06:49:31] <Ayush Mishra> Although, if people are switching to BBR and reporting better throughput, that would be one way of saying they were suffering when they used conventional CC? But yes, that would not indicate if this poor performance was because of newer CCs sharing the bottleneck
[06:49:44] <Jana Iyengar> So, this is a difficult thing to do. Trying to be not terribly unfair to legacy CC is a tall order, and I am very much interested in having a conversation about how we might change our thinking on this. I am being deliberately controversial here, but we ought to think about "unable to upgrade" as intolerable.
[06:50:03] <Jana Iyengar> It's 2020. This isn't a good enough excuse anymore.
[06:50:10] <Carsten Bormann> unfair ≠ starvation, which is really the harm we need to avoid
[06:50:13] <Brian Trammell> i might be too modern but I don't think that's all to controversial
[06:50:15] <Spencer Dawkins> @Christian, when we were doing IETF Last Call on MPLS over UDP, that was the statement. I think it's largely true for MANAGED networks.
[06:50:23] <Ayush Mishra> +1 Carsten
[06:50:37] <Jonathan Morton> @yuchung Imagine a CDN operating an aggressive CC, competing with a normal webserver with say CUBIC, the CDN might swamp end users' connections so hard that the normal webserver seems "unreliable" to the end user
[06:51:00] <Jana Iyengar> @Brian: yes, please include the jabber logs.
[06:51:00] <Brian Trammell> spencer: networks of any appreciable scale that are connected to the Internet that are not managed enough to manage partial congestion collapse are vulnerable to trivial DDoS in the 2020 Internet
[06:51:18] <Carsten Bormann> Jonathan: Web servers have a short upgrade cycle
[06:51:18] <Brian Trammell> this is the thing that people queued at the mic to say to Christian :)
[06:51:44] <Christian Hopps> Forced upgrade again makes me wonder about disenfranchisement.. perhaps it's not an issue, but what if it is?
[06:51:57] <Jana Iyengar> +1 Brian
[06:52:04] <Christian Huitema_858> Flip side: wireless connection state varies rapidly. Aggressive CC can track that, delivers much better perf than legacy. Is that bad?
[06:52:05] <Spencer Dawkins> @Brian - see IoT-based DDOS examples that are pretty common, when I looked a year or two ago. Yes. Agreed.
[06:52:14] <Ayush Mishra> @Jana true, but we need to be careful about making drastic changes to algorithms that essentially take care of (bandwidth) resource management for the world's largest distributed system!
[06:52:31] <Brian Trammell> Christian (Hopps): yes, but, the security posture of the Internet has already made non-upgrade unsafe.
[06:52:46] <Brian Trammell> holding back from upgrading doesn't fix the disenfranchisement
[06:52:52] Jay Iyer joins the room
[06:52:54] <Christian Hopps> Brian, interesting point.
[06:52:55] <Jonathan Morton> inerject now: "Reno friendly if classic ECN botleneck" DOES NOT WORK as shown in March
[06:52:56] <Brian Trammell> because it's already happened
[06:52:58] <Ingemar Johansson> There are a whole bunch of reasons why one should not stock with old gear for too long. Congestion control is one of the minor arguments :-)
[06:53:34] <Ingemar Johansson> *stick to*
[06:53:36] <Spencer Dawkins> + Brian and Ingemar
[06:54:25] <Jonathan Morton> a lot of material in Bob's presentation right now has already been discussed extensively in TSVWG
[06:54:41] <Christian Hopps> Do botnets even bother with low bandwidth poor countries? Are they equal opportunity attackers? :)
[06:55:23] <Christian Huitema_858> My server gets ping by attacks from Zimbabwe, so yes they do
[06:55:33] Loren McIntyre leaves the room
[06:55:36] Randy Bush leaves the room
[06:55:55] <Christian Huitema_858> Lost audio?
[06:55:59] <Carsten Bormann> No
[06:56:07] <Brian Trammell> bots on low bandwidth networks or in low-trust networks are cheaper to rent
[06:56:09] <Szilveszter Nadas> On related articles a referred to these:Brown, Lloyd, et al. "On the Future of Congestion Control for the Public Internet." Proceedings of the 19th ACM Workshop on Hot Topics in Networks. 2020.
Ware, Ranysha, et al. "Beyond Jain's Fairness Index: Setting the Bar For The Deployment of Congestion Control Algorithms." Proceedings of the 18th ACM Workshop on Hot Topics in Networks. 2019.
Trevisan, Martino, et al. "Five years at the edge: Watching internet from the isp network." IEEE/ACM Transactions on Networking 28.2 (2020): 561-574.
Briscoe, Bob. Per-Flow Scheduling and the End-to-End Argument. Discussion Paper TR-BB-2019-001, bobbriscoe.net, 2019.
[06:56:09] <Jana Iyengar> @christian: audio is fine
[06:56:10] <Christian Huitema_858> I did..
[06:56:11] <Ingemar Johansson> @Jonathan there was discussion on TSVWG that more info was wanted so it is definitely relevant to present it here
[06:56:12] <Spencer Dawkins> @Christian Hopps - I suppose not as targets, but as an available source of bot attackers, sure.
[06:56:15] <Szilveszter Nadas> 2 of these you linked
[06:56:16] <Brian Trammell> but not everyone is running a booter
[06:56:22] <Brian Trammell> some people just want to phish you
[06:56:39] <Szilveszter Nadas> Yes, another way is to create a good migration path for new CCs
[06:56:48] <Jana Iyengar> @Ayush: We don't actually control deployment, that happens organically. This happened with BBRv1. Things that are useful for end users will get deployed quickly, whether we change our posture on what is "good enough" or not.
[06:56:58] <Szilveszter Nadas> That sounds quite challenging.
[06:57:31] <Brian Trammell> I have a hard stop in three minutes. Wes, can you finish up the discussion notes?
[06:59:00] <Lars Eggert> i think esp. for short flows, doing worse then CUBIC for 5 seconds is not great?
[06:59:16] <Praveen Balasubramanian> @Jana, local useful != global useful. the challenge is measuring impact on cross traffic that one cannot see
[06:59:53] <Jana Iyengar> @Praveen : Of course. But that is a far cry from "ensure that legacy flows don't get affected"
[07:00:26] <Wesley Eddy> @Brian: yes
[07:00:27] <Jana Iyengar> ... and on that point -- Ranysha will be talking about "hurt"  in IRTF Open, which I think is quite interesting
[07:00:28] <Szilveszter Nadas> I think that small degradation is OK.
[07:00:51] <Ayush Mishra> @Jana I agree gradual deployment is hard. I am thinking about how we can cushion the blow of this organic adoption of cc algorithms by consciously making them traditional TCP friendly
[07:00:53] <Brian Trammell> \o heading out. i'll finish the jabber log dump once they end up on the server. have a good rest of the meeting all (or, alternately, see you in TSVAREA)
[07:00:56] Brian Trammell leaves the room
[07:01:07] <Szilveszter Nadas> Especially BBrv1 was quite agressive to Cubic, yes it is useful for those on BBRv1, but can be quite bad for legacy traffic
[07:01:08] <Lucas Pardue> focus on tcp fairness seems short-sighted in a world switching to UDP-based teleconferencing a transport
[07:01:30] <Lucas Pardue> and*
[07:01:53] <Jonathan Morton> UDP based transports still need congestion control, and will often use one similar to TCP
[07:02:04] <Szilveszter Nadas> UDP-conferencing can also use rate based CC, but fate sharing with TCP delay + loss can be problem
[07:02:12] <Jake Holland> "hurt" is a really interesting metric, yes.  Particularly interesting if it can be applied by a network as degradation with an enforcement mechanism, like the csaqm stuff does basically.
[07:02:15] <Szilveszter Nadas> Especially for e.g. streaming based gaming,
[07:02:19] <Lucas Pardue> right, so if needs a different label
[07:02:50] Bhavit Shah leaves the room
[07:02:54] <Szilveszter Nadas> @Jake can you explain "degradation with an enforcement"
[07:03:02] Balazs Varga leaves the room
[07:03:11] <Jake Holland> degrading traffic that is causing harm to other traffic
[07:03:24] <Jake Holland> my understanding of your csaqm is basically that it does exactly this, right?
[07:03:25] <Szilveszter Nadas> thx
[07:03:34] <Szilveszter Nadas> it inforces a policy
[07:03:39] <Szilveszter Nadas> *enforces
[07:04:27] <Szilveszter Nadas> so if e.g. flow fairness is the policy it enforces that, so it "degrades" otherwise aggressive flows
[07:04:33] <Jake Holland> yes, i think if we can't rely on senders to be responsible with their cc choices, particularly as you get experimenting in apps with who knows what ultimately, you basically need some kind of enforcement in the network.
[07:04:50] Nick Banks leaves the room
[07:04:50] Geoff Huston leaves the room
[07:04:52] <Szilveszter Nadas> but it can enforce e.g. Hierachy of policies e.g. user fairness and flow fairness within.
[07:05:19] <Lars Eggert> so one thing that i will spend some time on is building a vagrant box with the L4S kernel and mininet installed, to make it easier to run some experiments. i'll announce when it's ready (depends on getting a dpkg nightly from L4S, etc.)
[07:05:29] <Jana Iyengar> @Jake: I would argue that that's been happening for a while already.
[07:05:40] Jay Iyer leaves the room
[07:05:41] <Jake Holland> in some places, yes :)
[07:05:42] <Lars Eggert> (i don't just want to criticize, i'd like to help generate data)
[07:05:43] Yanmei Liu leaves the room
[07:05:51] <Szilveszter Nadas> "enforcement in the network" - so CSAQM and HQoS and fq-* can all be used for that
[07:05:53] <Gorry Fairhurst> @Lars ... sounds wonderful!
[07:06:00] <Szilveszter Nadas> Questin is whihch one can be deployed
[07:06:05] <Peter Heist> tx Lars :)
[07:06:22] <Szilveszter Nadas> Esp for bottlenecks not in the ISP network.
[07:07:26] Mihail Zverev leaves the room
[07:07:42] Dmitri Tikhonov leaves the room
[07:08:06] <Szilveszter Nadas> Just highlighting again: we have much more results at the links I posted, including TCP Prague preliminary results.
[07:08:19] Hajime Fujita leaves the room
[07:08:43] John Border leaves the room
[07:09:09] Nicolas Kuhn leaves the room
[07:09:09] <Gorry Fairhurst> I left the queue .. let's use the ICCRG list to talk about this cool stuff.
[07:09:10] Vidhi Goel leaves the room
[07:09:11] Chi-Jiun Su leaves the room
[07:09:12] Michael Scharf leaves the room
[07:09:14] Luke Curley leaves the room
[07:09:14] Eric Kinnear leaves the room
[07:09:14] Rohit Abhishek leaves the room
[07:09:15] Kiran Makhijani leaves the room
[07:09:15] Andrew McGregor leaves the room
[07:09:16] Lv Yunping leaves the room
[07:09:16] Nitin Batta leaves the room
[07:09:16] Richard Scheffenegger leaves the room
[07:09:16] Yuchung Cheng leaves the room
[07:09:17] Alessandro Ghedini leaves the room
[07:09:17] Marcus Ihlar leaves the room
[07:09:18] Marten Seemann leaves the room
[07:09:18] Luis Contreras leaves the room
[07:09:19] Yunfei Ma leaves the room
[07:09:20] John Kaippallimalil leaves the room
[07:09:20] Markus Amend leaves the room
[07:09:21] Colin Perkins leaves the room
[07:09:22] David Black leaves the room
[07:09:22] Greg White leaves the room
[07:09:23] Lohith Bellad leaves the room
[07:09:23] Lars Eggert leaves the room
[07:09:23] Carsten Bormann leaves the room
[07:09:23] Praveen Balasubramanian leaves the room
[07:09:23] Zhen Cao leaves the room
[07:09:24] Kazuho Oku leaves the room
[07:09:24] Kazuaki Ueda leaves the room
[07:09:25] Jonathan Morton leaves the room
[07:09:25] <Jake Holland> fantastic session :)
[07:09:26] Christian Hopps leaves the room
[07:09:26] Steffen Klassert leaves the room
[07:09:26] Igor Gashinsky leaves the room
[07:09:28] Philipp Tiesel leaves the room
[07:09:28] Joakim Misund leaves the room
[07:09:29] Igor Lubashev leaves the room
[07:09:29] Wu Zhao leaves the room
[07:09:34] Christian Huitema_858 leaves the room
[07:09:35] Meetecho leaves the room
[07:09:36] <Ingemar Johansson> Great session, thanks!
[07:09:37] Frode Kileng leaves the room
[07:09:39] Wesley Eddy leaves the room
[07:09:42] Jiao Kang leaves the room
[07:09:44] Ingemar Johansson leaves the room
[07:09:48] <Jana Iyengar> Bob -- was that sarcastic? :-)
[07:09:52] Dirk Hugo leaves the room
[07:09:52] <Ayush Mishra> Thanks!
[07:09:53] Koen Schepper leaves the room
[07:09:58] <Mirja Kühlewind> Thanks!
[07:09:59] Eckard Bogenfeld leaves the room
[07:10:02] Dragana Damjanovic leaves the room
[07:10:04] Mirja Kühlewind leaves the room
[07:10:08] Ayush Mishra leaves the room
[07:10:09] <Bob Briscoe> @Jana. Not at all.
[07:10:10] Lucas Pardue leaves the room
[07:10:29] <Bob Briscoe> It really was a great session, and you allowed flex, where it was needed
[07:10:40] Anna Brunstrom leaves the room
[07:11:00] Gorry Fairhurst leaves the room
[07:11:07] <Jana Iyengar> Anna, apologies we couldn't get to your talk
[07:11:23] Szilveszter Nadas leaves the room
[07:11:45] Mihail Yanev leaves the room
[07:11:52] Jana Iyengar leaves the room
[07:12:20] Paolo Saviano leaves the room
[07:12:20] Stuart Cheshire leaves the room
[07:12:20] Spencer Dawkins leaves the room
[07:12:20] Jake Holland leaves the room
[07:12:20] Peter Heist leaves the room
[07:12:20] Bob Briscoe leaves the room
[07:12:20] Chunshan Xiong leaves the room
[07:12:20] Quang-Huy Nguyen leaves the room
[07:12:20] Neal Cardwell leaves the room
[07:12:20] Zongpeng Du leaves the room
[07:12:20] Philip Eardley leaves the room
[07:12:20] Hirochika Asai leaves the room
[07:12:20] Markku Kojo leaves the room
[07:12:20] Mike English leaves the room
[07:12:20] Jörg Deutschmann leaves the room
[07:12:20] Zhuangyan leaves the room
[07:12:21] Juhamatti Kuusisaari leaves the room
[07:12:21] Yoshifumi Nishida leaves the room
[07:12:21] Mihail Yanev joins the room
[07:15:46] alex-meetecho leaves the room
[07:16:14] spencerdawkins leaves the room
[07:22:16] frodek leaves the room
[11:14:43] Christian Huitema leaves the room
[15:24:56] ihlar leaves the room
[18:30:00] ihlar joins the room
[22:04:30] ihlar leaves the room