8/11 Discord Meeting

[nibanks]

Agenda

• Status updates
  • Release 2.0
• Discuss Grease bit PR

[dahavey]

Meeting Notes:
08.11.2022 - MsQuic Public Discord

Thursday, August 11, 2022
10:10 AM

• 

…Last meeting ran over. Arrived late. Notes begin here
• Splitting up numa nodes will be tricky
• At the app layer we need a singleton for the API
○ The data path is shared across all apps - you can't have two threads driving the same thing
○ Multiple apps will not need to drive MsQuic
§ Only a singleton app
○ Default case will be where you don't doo anything. You just get callbacks
○ MsQuic open, then setAPPExecContext - call anything that makes thread and you own it.
• Finished migrating MsQuic .NET server
○ Build very old, needs updating
§ Will look into this. Running into problems
§ Just try another build
□ Using STACK because our latest is not in OneCore yet
® It will be in OneCore tomorrow
• Linux packaging
• We use docker to build official builds and sign
○ OneBranch is retiring the custom images that we use.
○ Mad some progress
§ OneBranch pipeline - have isolated Azure CR
§ Will change code to consume above
○ Now we are using a shared ACR called Docker image pass
§ Will change to use new isolated ACR
○ Why did we use Docker in the first place?
§ We just need a bunch of build tools and it is nothing special.
○ High level goal is to have a sandbox
§ It's all about security
□ Secure the container and run everything in there.
□ Doesn't even need to access the Internet.
□ That is the goal.
□ Cut off all Internet access.
§ Assume that you cannot use the Internet inside the container
□ But we do use the Internet
□ Split this into two stages
® The build container can stay the same until we have to upgrade the build tools.
® Our code will change but the container environment does not.
® Anything that needs to access the Internet is part of the build container stage
◊ This is the long term goal.
• Planning process is underway
• Please take a look at the task costing and provide accurate feedback
○ Especially costing. Don't underestimate.
• Implement grease bit extension
• QUIC bits can be set to 0 or 1
○ Zero - other extensions can use it
○ One -- ?
• Grease - changing something semi-randomly so that nothing on the Internet ossifies
○ There is a fixed bit in the header that is always set to 1
§ We don't want this to ossify
§ If any bit is always the same then middleboxes will ossify on it.
○ Connection can dynamically decide whether or not to grease the bit
○ The extension is an agreement to ignore that bit and you can set it to whatever you want.
• In design stage.
○ Make sure to set the fixed bit to another value depending on the state
• The bit is in the clear text part of the header
○ Anything in the encrypted part does not need greasing because it is already changing.
• ALPN
• .NET team wants changes in the ALPN in the listener
○ Want to set configurate for the callback
○ However this is asynch so we cannot have changes except at the….
○ Cannot get the ALPNs from there, must make sure that we already have the list of ALPNs. Suggestions?
§ We do nothing and pass this down to TLS expecting them to do this.
□ Might be already hooked up.
□ Better for us to have the logic to do the match again as needed
□ Where we set neg ALPN we should cache the client list
® We also have a pont to the client ALPN list
◊ This points into the TLS packet and lives long enough so that you can walk the list again at config time.
® Just save the pointer and then if the neg ALPN == the first item of new config: do nothing - fast path
◊ Else go through the config and client list walk and pick the most preferred.
® Should I check the new ALPN with the listener ALPN list?
◊ No, that will happen anyways.
○ Allows for per SNI ALPN
§ When you create a listener you don't specify the config
□ They have to call set config.
® We can do inline or asynch
§ This is already a required state for both http stack
§ .NET is taking this a step further
Asynch set the cert and other TLS config