[HTTP/3] Consider including QUIC dependencies in Docker images

[JamesNK]

Update Docker images at https://hub.docker.com/_/microsoft-dotnet to include Linux dependencies required for HTTP/3.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Update Docker images at https://hub.docker.com/_/microsoft-dotnet to include Linux dependencies required for HTTP/3.

Author:	JamesNK
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Triage: this is nice to have and might not even be possible due to increasing image size.

[karelz]

Triage: Work will not happen here. We should make it happen in 7.0 -- once msquic packaging is finalized.

[ManickaP]

Triage: this is not a runtime issue and should be transferred into appropriate repository for consideration.

Recommendations:

• add it to the image as we do provide nice experience on Windows
• if not, we should include Microsoft package repository key in the docker images to make installation there easier

cc: @wfurt

[richlander]

We typically don't add dependencies for specific APIs. We made this choice of LDAP, for example. It's a question of whether we think HTTP3 is different.

[mthalman]

[Triage]
Since this is opt-in functionality, it seems reasonable to also require the explicit addition of QUIC to the image. This is not something that should be included by default given it is not currently a mainline scenario. As Rich mentions above, this is in line with other cases that are not common and require an additional package to be installed.

[ManickaP]

@mthalman should we at least consider adding Microsoft Linux package repository to the images: https://learn.microsoft.com/en-us/windows-server/administration/linux-package-repository-for-microsoft-software#configuring-the-repositories?
So that users can just apt install ... the package.

cc: @richlander

[richlander]

The Microsoft package repository is not side-effect free, in particular since .NET is also there.

In any case, we'd like to see some more user evidence that we need to act here.

We're not going to do anything until the OpenSSL3 issue is resolved. All of the base images have moved to use it now.

[JamesNK]

Since this is opt-in functionality, it seems reasonable to also require the explicit addition of QUIC to the image.

HTTP/3 will be enabled by default in ASP.NET Core in .NET 8 (if the platform supports it, e.g. running on a minimum version of Windows, or has necessary packages on Linux).

Might want to reconsider for the aspnetcore runtime docker image.

[richlander]

That fact that it is enabled by default seems unimportant. We don't include packages for other features. Other components load dependencies in a dynamic nature.

If 100% of users need it, then we would include it. If not, then other metrics like library size become important. Opt-in works as a fine model, where different users get to make their own choices. We'd prefer not to take that away from them.

[Misiu]

if this won't be included by default (I won't argue on the decision), then at least it should be clearly described in the docs how can we install it manually, ideally with a sample dockerfile.

[richlander]

We've been looking into this topic area a bit more.

libmsquic via this Dockerfile adds 14MB to runtime-deps. That's a lot.

https://gist.github.com/richlander/58a3a8b11960a37d1a99adcbcc16ea47

These are also relevant:

• Announcement: New approach for differentiating .NET 8+ images #4821
• Provide base image for Native AOT #4748 (comment)

There are a variety of (practical) options on the table:

• Add libmsquic to the extra images. There will be some folks that want icu and libmsquic but plenty who want just one. The former is 36MB and the latter is 14MB, both uncompressed (probably about 20MB compressed, together).
• Add libmsquic to arbitrary images via SDK container builds via automagic download at publish time.

These two options are not mutually exclusive.

[richlander]

I validated the costs of libmsquic, compressed (in a container image).

• baseline: 29.18MB
• + ICU: 43.22MB
• + msquic: 47.08MB

What the baseline is doesn't matter. The compressed cost of msquic is 3.86MB.

[andrew-from-toronto]

I've been looking into how to add libmsquic into the chiseled images and have been running into problems (needed a slice, created a slice, but still isn't working 🤷). The fact that there is no guidance around this in the docs is surprising. I don't mind it being something we have to add if we want it, but the lack of documentation hurts

Here's what I've got so far for ref https://gist.github.com/andrew-from-toronto/1bfea30377d3e408ae3dd06784a4802d (this doesn't work last I tried if you end up here)

[richlander]

Fair enough. There should be better guidance. We should provide a Dockerfile for the regular case and then discuss what to do about chiseled. That will be more complicated.

[richlander]

We should re-discuss this one @lbussell

[MichaelSimons]

The tracking issue for better chiseled documentation for adding additional packages is #4811.

[richlander]

I don't think that helps. There is an ask for docs for non-chiseled scenarios and I'm guessing whatever general instructions we create won't work for libmsquic.

[andrew-from-toronto]

Yeah I tried following all the examples I could find in the linked (-R) issues, but I think because libmsquic is not in the ubuntu repo there are some gotchas. Just guessing because I never got it to work. For now I'll just use the normal aspnet image and install libmsquic there, but would still love to see guidance for chiseled images so I can switch back in the future.

[lbussell]

[Triage] @richlander will the samples be sufficient for us, instead of adding libmsquic to the extra images or some other solution? AKA should we close this again if we've decided to create the samples?

[richlander]

Yes. Samples will be sufficient. Closing, leaving #5468 active.