61–70 of 329 posts
At a glance, this sounds very similar to AWS' SRD protocol [1] - I'm curious how they compare but I see no mention of SRD in this paper. [1] https://assets.amazon.science/a6/34/41496f64421faafa1cbe301c...
There's a little misleading point on page 2, or just a mistake. It says "Driving a 100 Gbps network at 80% utilization in both directions consumes 10–20 cores just in the networking stack" and it cites Google's Snap paper from 2019. But the Snap paper quite clearly says nothing like that. It says that Snap can drive a 100gbps NIC to 80gpbs with just 1.05 cores (Table 1) and that the whole-machine CPU load at 80gpbs i…
Yes that stat stood out for me too and I was wondering how to actually test this without breaking anything in the process.
dpdk has been doing just that for quite some time now. perhaps you can try that and see ?
Yes!!! I have been saying for years that lower level protocols are a bad joke at this point, but nobody in the industry wants to invest in making things better. There are so many improvements we could be making, but corporations don't see any "immediate shareholder value", so they sit around happy as pigs in shit with the status quo. What's kind of hilarious about this paper is, these are just the network-layer probl…
Your ideas are interesting, can you link to or explain a concrete example though? The idea of everything magically debugging itself doesn't apply to a single piece of software I've ever seen, so I'm curious what kind of design would lead to that being possible.
Yes!!! I have been saying for years that lower level protocols are a bad joke at this point, but nobody in the industry wants to invest in making things better. There are so many improvements we could be making, but corporations don't see any "immediate shareholder value", so they sit around happy as pigs in shit with the status quo. What's kind of hilarious about this paper is, these are just the network-layer probl…
What is QUIC in your book? Given, say, $50 million of dev time, what would you go about fixing? And in what way?
Earlier quoted context omitted.
The handshake sequence is exaggerated. It's just usually 3 messages. The 3 initial messages establish a connection. A: I would like to tell you something. (SYN) B: I acknowledge you want to tell me something. (SYN-ACK) A: I received your acknowledgement. (ACK) After the handshake sequence is done, data transfer begins. Only then, it is possible to know that the "something" was a joke. If B answers with RST instead of…
You're missing the frame size comms that then occur following this.
Yes!!! I have been saying for years that lower level protocols are a bad joke at this point, but nobody in the industry wants to invest in making things better. There are so many improvements we could be making, but corporations don't see any "immediate shareholder value", so they sit around happy as pigs in shit with the status quo. What's kind of hilarious about this paper is, these are just the network-layer probl…
Surely most of your ideas are already being deployed in QUIC/HTTP3. It just happens inside a UDP datagram, for compatibility. Really you're not going to see any new IP protocol layers, there's too much quirky hardware on the network that wouldn't be able to handle it. If we can't even get IPv6 to work all the way to the client, we're never seeing new values for the protocol byte.
Earlier quoted context omitted.
What is QUIC in your book? Given, say, $50 million of dev time, what would you go about fixing? And in what way?
Doesn't QUIC still run over TCP? I thought it was a replacement for HTTP not TCP (Edit: looks like it replaces TCP and HTTP)
The RFCs are a bit elaborate so folks interested might want to look at this instead[1], which has one of the RFC authors explaining the basics of QUIC and HTTP/3.
Earlier quoted context omitted.
It's theoretically much easier to introduce a new transport inside of a DC, since you're inside the network perimeter and you'll generally have control over policy-based filtering decisions.
The context here is TFA advocating for use of higher-level message-oriented frameworks instead of raw socket APIs so that they can use a non-TCP transport without changing the application code.