Hi everybody,
I'm a complete outsider, but it seems to me that the effort to decide
and remember where and when to use checksums and when not may quickly
get bigger than the effort to just checksum everything.
Regards, Martin.
On 2024-03-13 18:13, Shihang(Vincent) wrote:
Hi Christian,
The idea of trial is interesting. I wonder if the trial should be done per path
or per end host? Are you assuming some middleboxes will mess up the NULL
checksum UDP packets?
Thanks,
Hang
-----Original Message-----
From: QUIC <[email protected]> On Behalf Of Christian Huitema
Sent: Wednesday, March 13, 2024 12:51 PM
To: Martin Thomson <[email protected]>; [email protected]
Subject: Re: Can I set the UDP checksum to zero when running QUIC?
One the other hand, the cost of computing the checksum is tiny compared to the
cost of encrypting the packets. So there is a small performance gain in not
computing the checksum, compensate by the potential gain of loosing
compatibility.
If I were to do that, I would do some trials. Until the handshake is complete,
use the checksum. Then, send a trial packet with null checksum. If the peer
acknowledges it, then further packets can be sent with null checksum. Redo the
trial for each new path, or if there are large number of packet losses.
Basically, treat that the same way we do PMTUD.
-- Christian Huitema
On 3/12/2024 3:57 PM, Martin Thomson wrote:
The question is more of a compatibility one than anything else. What, if
anything breaks if you do this?
As noted, there are contexts in which not computing the checksum works. So I
guess the conclusion is that nothing breaks, so go ahead. QUIC doesn't depend
on the checksum. All the cryptographic bits of QUIC use far stronger and more
reliable mechanisms.
On Tue, Mar 12, 2024, at 22:04, Shihang(Vincent) wrote:
Hi QUIC wg,
Since QUIC has strong encryption and integrity protection provided by
TLS 1.3. I wonder if the UDP checksum can be disabled(using UDP Zero
Checksum Mode https://www.rfc-editor.org/rfc/rfc6936 )to save the
computation just like in VXLAN(RFC7348
<https://datatracker.ietf.org/doc/html/rfc7348#autoid-12>).
Thanks,
Hang
