HTTP/3

62 views
Skip to first unread message

Antonio Ojea

unread,
Jan 9, 2022, 7:18:29 AM1/9/22
to K8s API Machinery SIG
Hi all,

I've started to work on the networking area of the apiserver recently and I've identified that one area for improvement: the performance of the control plane network on environments with adverse networking conditions like netwrok packet loss, jitter, latency, ...

The resilience on these environments was fixed with HTTP/2 and enabling health checks [1], so the clients can detect stale connections and recover in ~ 30 seconds (before was more than 15 mins). 

However, HTTP/2 is still impacted by Head of Line Blocking, any interruption (packet loss) in the TCP connection blocks all streams ( the OS will handle the retransmissions, but all data impacted has to be re transmitted in the TCP stream).

HTTP/3 solves the Head of Line Blocking problem (and some others [2],[3]) because is UDP based, it uses QUIC for transport (RFC9000), and only the stream affected by the packet loss is interrupted.

Quoting the wikipedia article [4]

> As of January 2022, the HTTP/3 protocol is still officially an Internet Draft, but is already supported by 73% of running web browsers,[3] and according to W3Techs 24% of the top 10 million websites. 

There is also a golang implementation [5] that is being used by known projects and companies.

I've made a proof of concept [6] implementing HTTP/3 in the apiserver and client-go,  there are some edges, main problems are number of dependencies that it brings and it will require some discussion on how to define the UX: opt-in, upgrade from http, ...

I'd like to have feedback about the idea of implementing HTTP/3 on client-go and the apiserver. I think this will be a feature like IPv6, that will take a long time to graduate, but having it working we can have early feedback, so we can influence the implementation (in golang), instead of lagging behind and had to adapt later.

Regards,
Antonio Ojea


Mike Spreitzer

unread,
Jan 10, 2022, 8:59:04 AM1/10/22
to Antonio Ojea, K8s API Machinery SIG

I have not had time to look into the details, and am unlikely to do so soon, but I support this in general.  The head of line blocking problem is why http/2 did not happen earlier (when we called it HTTP-NG).

 

-- 

Thanks,

Mike

 

 

From: <kubernetes-sig...@googlegroups.com> on behalf of Antonio Ojea <antonio.o...@gmail.com>
Date: Sunday, January 9, 2022 at 7:18 AM
To: K8s API Machinery SIG <kubernetes-sig...@googlegroups.com>
Subject: [EXTERNAL] [k8s API machinery] HTTP/3

 

Hi all, I've started to work on the networking area of the apiserver recently and I've identified that one area for improvement: the performance of the control plane network on environments with adverse networking conditions like netwrok packet ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd
Hi all,

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/8cfd24b9-db7c-4423-b374-a3c7bf7dc233n%40googlegroups.com.

Antonio Ojea

unread,
Jan 18, 2022, 11:50:57 AM1/18/22
to Mike Spreitzer, K8s API Machinery SIG
I've created a KEP for adding HTTP/3 support to the apiserver:

https://github.com/kubernetes/enhancements/pull/3159

If anybody considers it interesting and wants to reviewer/approver please let me know.

Regards,
Antonio Ojea
Reply all
Reply to author
Forward
0 new messages