pull down to refresh

Does something like TCP even make sense in a sneakernet scenario? I mean, max packet size of TCP is 64k and sure we could put many packets on a storage device, but why even use a connection-based protocol with retransmissions and congestion control? I can see the value in having a sneakernet protocol at the application layer but it seems like gateways between the networks of networks should be determining the transport protocol.
That's all to say sneakernets have a totally different set of requirements than the internet protocol, right?
So we would seriously have to have a conversation about increasing the block time, but also the block size in the same conversation. Could end up with the same aggregate data size build up over time (same effective block size for the given block time), but who knows how that imaginary conversation might go anyway.
I wonder what relationships reorgs have to block propagation speeds. If we made the difficulty adjust based on a less frequent block schedule and block propagation latency increased by several orders of magnitude, I suspect chainsplits would be super common. We should be able to model the relationship between these though.
This reminds me of something I read once, where they were measuring bandwidth of FedExing a bunch of big hard drives across the country. A kind of sneakernet but with quite different assumptions. It would make sense in some cases, I expect; for packet loss, you send one set of drives via FedEx and one by UPS.
reply
I used to work at Aspera (before they were acquired by IBM ... sad to see they no longer have their own website) and our main competition at the time was physical transport of hard drives.
reply
Yeah you're right, but you know I'm thinking of a lot of different data transmission methods and when I have a big bunch of them with tradeoffs that work in one area but not another or situation but not another, I'll start to think of interoperability between them and what the best protocol for all of that really is.
The fact that you could technically do it all over TCP is more neat than it is practical.
reply
Yeah I can imagine using TCP from one gateway to another. It just seems like for a legit sneakernet you wouldn't want to use TCP at the edges.
reply
So just to add, sneakernet may not always be the edges. People at various country borders have legitimate reasons to cross a border every day, and then pass their data to the next hop for example. May even be less risky than pointing an IR laser across the border or something like that. But morse code encoded IR flashlights can be mobile (you know it should be in a general area) but then there's false data (so transmission by an attacker to confuse or denial of service this method), but zip that's for another day lol.
Thinking of doing dronenets next what do you think?
reply
Oh good point. But the point of points is that ideally the transport is irrelevant. A snearknet is a transport protocol, yet to properly be a protocol it would probably need an addressing scheme and gateways to networks that use other transport protocols.
Thinking of doing dronenets next what do you think?
idk. I'd be more interested in how we might create a legit global sneakernet protocol that covers less breadth of considerations and goes deep on requirements and details.
reply