7/14 Discord Meeting

[nibanks]

Agenda

• Should we move (at least some of) the tools out of MsQuic into their own repo, like quicreach?
  • Pros: They can have their own issues, history, and dashboard.
  • Cons: Requires a separate commit to update MsQuic + Tool.

[dahavey]

• Light agenda today
	○ Looking at Azure pipeline for interop testing
	○ Adding support for version 2
		§ Need to remove inactive interop servers
	○ QuicReach
		§ Determines reachability of networks once a day
			□ Checks the top 5000 severs
			□ How many take multiple RTTs to connect
			□ How many send too much data from the server side in first RTT (amplification attacks)
			□ 13 servers of the hostname list (5000) respect the protocol rules
		§ Quic Interop dashboard
			□ Right now we only make sure there are no crashes
			□ We could use the data to produce an interop dash
		§ Separate out the perf dashboard data
			□ Standardize multiple impl perf testing
			□ Test against the perf of all the major QUIC impls
		§ SpinQuic
			□ More of a stress test than a tool
			□ Should just be under tests rather than tools
• What do we do about tools?
• Should we move the standalone tools out?
	○ Interop
	○ Perf…maybe
• Discussion
	○ Good to have everything in the same repo, convenient
	○ Otherwise you have to make multiple PRs to different repos
	○ Can use tags for organization
		§ But, you can't get separate dashboards
• QuicReach already has 108 commits
	○ All this data goes into 1 CSV file
• Should we have perf, interop data branches?
	○ How will this scale?
		§ We already have thousands of commits
	○ Just create a repo with all the data(?)
		§ MsQuic dashboard data -- repo
		§ Everything pushes there
	○ We don't need the data to live in our repo because we don't look at the raw data directly
	○ However, you only get 1 webpage per repo so we can't build separate dashboards
• Can't make releases for portions of the code
• Flow blocked timings
	○ Change param to streams_stats

Don't overthink it, just add the stat if is quick and easy.