Re: The TCP and UDP checksum algorithm may soon need updating

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Fri, Jun 5, 2020 at 12:01 AM Joseph Touch <touch@xxxxxxxxxxxxxx> wrote:


On Jun 4, 2020, at 7:57 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:

Consider the case in which I am transfering a 60GB 4K movie over the net. Say for the sake of argument there is a 1% chance of a one bit failure.

There are a lot of statistical assumptions in that statement.

How about somebody showing an actual case where this has happened, please?

Before we solve a problem in theory rather than in practice.

Has anyone been looking? The security area has always been interested in theoretical attacks. They are by far the best kind. 

I was throwing those numbers out to point out what is now a routine sort of communication.


It is clear that as the size of bulk transfers increase, the probability of a transmission failure that is not detected by the transport layer approaches 1. Traditionally, we just ignored the risk. That was probably an acceptable response in the days when we bought memory in 128K modules. Those assumptions no longer hold.

SHA-2-256 is good for pretty much any feasible data transfer. But HTTP certainly isn't and neither is QUIC. And it would be kinda silly to conflate a protocol designed to support fast interactive response for Web browsing with bulk data transfer. 

The Mathematical Mesh has two separate messaging systems. There is a control plane where the messages are limited to ~32KB (not certain that is the sweet spot yet but less than 64K). And there is a data plane for bulk messages that will be eventually engineered to support Terabyte and Petabyte transfers.

It is pretty clear that the current transport checksum is sufficient for my control plane. It is equally clear that the data plane can't rely on any imaginable transport layer checksum to support Petabyte transfers. So I am fine with the transport checksum either way.


Sure, I have taken some extreme points on the curve here and there might be a point inbetween where it makes sense to upgrade the transport checksum because it is causing issues at the application level. But the burden of proof is on people suggesting we need to change the transport checksum that such a position exists.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux