Confluent is pioneering a fundamentally new category of data infrastructure focused on data in motion. Our cloud-native offering is designed to be the intelligent connective tissue enabling real-time data, from multiple sources, to constantly stream across the organization.
We’re looking for backend engineers to join our cloud infrastructure networking team and help us improve connectivity, performance, reliability, and security. We are a team of passionate engineers who love solving complex distributed systems and infrastructure problems.
You’ll be able to have a big impact almost immediately and you will have the opportunity to own solutions end-to-end with a lot of autonomy. We’ll support your growth and actively look to help you develop your technical skills, ensure you’re doing work you enjoy, and make sure you’re advancing your career.
You may be interested in this: https://techcommunity.microsoft.com/t5/networking-blog/makin.... The gist is that yes QUIC has higher CPU usage but all OS platforms are investing in UDP hardware offloads and optimizations to level the playing field. While the only IETF standard that will come out is HTTP/3, our implementation MsQuic powers both HTTP/3 and SMB proving the general purpose nature of the transport. We are not there yet in terms of an application that's only powered by QUIC because UDP reachability is not 100%, so you need a fallback. Most apps will either use HTTP/3 and fallback to HTTP/2 or use QUIC directly and have to fall back to secure L7 over TCP.
It's called R(ecent) Acknowledgement and yes the work came out of Google. This is the single biggest change to TCP loss recovery in a decade. It is now a Standards Track RFC: https://datatracker.ietf.org/doc/html/rfc8985. The Windows implementation was one of the earliest amongst a handful and Microsoft participated in the standardization.
You are spot on. PktMon is the next generation tool in newer Windows 10 versions and brings many of the same benefits referred to in this blog - particularly being able to view packet captures and traces together in the same text file. And WPA is also very useful when analyzing performance problems.
PktMon is the next generation tool in newer Windows 10 versions and brings many of the same benefits referred to in this blog - particularly being able to view packet captures and traces together in the same text file.
* What are the reasons for disabling TCP timestamps by default? (If you can answer) will they be eventually enabled by default? (The reason I'm asking is that Linux uses TS field as storage for syncookies, and without it will drop WScale and SACK options greatly degrading Windows TCP perf in case of a synflood.[1])
* I've noticed "Pacing Profile : off" in the `netsh interface tcp show global` output. Is that the same as tcp pacing in fq qdisc[2]? (If you can answer) will it be eventually enabled by default?
Windows historically defaulted to accepting timestamps when negotiated by the peer but didn't initiate the negotiation. There are benefits to timestamps and one downside (12 bytes overhead per packet). Re. syncookies, that's an interesting problem but under a severe syn attack, degraded performance is not going to be the biggest worry for the server. We might turn them on but for the other benefits, no committed plans. Re. pacing profile, no that's pacing implemented at the TCP layer itself (unlike fq disc) and is an experimental knob off by default.
re. syncookies: Linux by default starts issuing syncookies when listening socket's backlog overflows, so it may be accidentally triggered even by a small connection spike. (This, of course, is not an excuse for a service misconfiguration but it is quite common: somaxconn on Linux before 5.4 used to be 128 and many services use the default.)
re: pacing: Awesome!! I would guess it is similar to Linux "internal implementation for pacing"[1]. Looking forward to it eventually graduating form being experimental! As a datapoint: enabling pacing on our Edge hosts (circa 2017) resulted in ~17% reduction in packet loss (w/ CUBIC) and even fully eliminated queue drops on our shallow-buffered routers. There were a couple of roadbumps (e.g. "tcp: do not pace pure ack packets"[2]) but Eric Dumazet fixed all of them very quickly.
Thanks for the heads up. We will investigate to see what fraction of connections end up losing these options.
Pacing TCP is certainly on our roadmap. Our QUIC implementation MsQuic paces by default already.
Do you have any details on how or when Microsoft will roll out quick in Windows? Will it work by just specifying the quick protocol when creating a socket like with tcp?
I have a question, why is it that when opening two sockets on Windows and connecting them through TCP, there is about a 40% difference in transfer rate when sending from socket A to B, compared to sending from B to A?
That's not expected. Are you using loopback sockets or are these sockets on different endpoints? Is this unidirectional or bidirectional traffic, i.e. are you doing both transfers from A to B and B to A simultaneously?
I see the issue both on the same computer, so loopback, as well as on two computers on the same LAN. I tested with unidirectional traffic. Pretty easy to test for yourself. The problem appears to be with the TCP protocol implementation. For UDP transmission speed is the same both ways.
I cannot comment on queuing disciplines and limits in future products. Re. TCP_NOTSENT_LOWAT, you may want to look at the Ideal Send Backlog API that allows an application to have just more than BDP queued to keep the performance at the maximum throughput while minimizing the amount of data queued: https://docs.microsoft.com/en-us/windows/win32/winsock/sio-i...
Connection migration is part of the current Internet-Drafts. The generalized support for multi-path (i.e. usage of more than one path at the same time) is postponed to a future version of the protocol. You can follow the standards work here: https://quicwg.org/
Good to hear, but it seems like using both paths at the same time would be necessary for connection migration to work well, as you're often not sure which connection is actually better. If you have to wait until you're completely sure one connection is gone before switching wholesale to the other, that removes a lot of the benefit of connection migration.
Confluent is pioneering a fundamentally new category of data infrastructure focused on data in motion. Our cloud-native offering is designed to be the intelligent connective tissue enabling real-time data, from multiple sources, to constantly stream across the organization.
We’re looking for backend engineers to join our cloud infrastructure networking team and help us improve connectivity, performance, reliability, and security. We are a team of passionate engineers who love solving complex distributed systems and infrastructure problems.
You’ll be able to have a big impact almost immediately and you will have the opportunity to own solutions end-to-end with a lot of autonomy. We’ll support your growth and actively look to help you develop your technical skills, ensure you’re doing work you enjoy, and make sure you’re advancing your career.
To apply in US go to https://www.linkedin.com/jobs/view/2736465947/. To apply in Europe go to https://www.linkedin.com/jobs/view/3189560718/.