Show HN: Ouroboros – A Decentralized Packet Network
ouroboros.rocks
ouroboros.rocks
https://ouroboros.ilabt.imec.be/index.html
And a direct link to a fantastic introductory video from FOSDEM:
https://www.youtube.com/watch?v=6fH23l45984
I'm really interested in ouroboros as a transit layer for systems like kubernetes -- of course you have to kind of rethink the interconnections between resources an but ouroboros look simple and cleanly composable -- it really feels like it could fit well.
I read the documentation and the FAQ, but it's all very nebulous. It's supposedly better, but no explanation is given to how or in what way.
I'd love to have a clear and understandable answer. I'm sure the project would benefit from having such an explanation on their web page.
What interests me is how simple, general, and composable it is though there are also some privacy gains (there's no need to know where a packet came from[1]). Let's say I write some application and today I want it to speak TCP, but tomorrow I want it to listen from a kafka queue, and the day after I want it to actually listen on UDP -- the benefit of using something like ouroboros is the layer under the communication could be anything. Take this one step further and you could switch out the configurations from underneath applications as well.
In an orchestrated context like kubernetes, IP networks introduce a lot of complexity -- the CNI (Container Network Interface) and setting up your networks, subnets, VPNs, etc requires that you bone up on what is basically "essential complexity" in the network space[2]. I've paid the cost somewhat (I'm not a dyed-in-the-wool sysadmin) so I can find my way around but every once in a while I lament how complex it all is when you put it together. With ouroboros, and applications that were coded to use ouroboros (or were coded to connect to a resource that is actually ouroboros underneath), I could actually skip setting up the entire network and maybe have all my messages go over something like a kafka queue. Whether this is a good idea or not aside, ouroboros is introducing an abstraction layer at the network layer -- but not just at one level... it's the entire stack.
For 90% of the usecases (especially this early), most of the networks made with ouroboros will be IP underneath, but I am really interested in the world where they won't be, and I think Ouroboros is a pretty elegant abstraction to take us there.
[0]: https://youtu.be/6fH23l45984?t=1333
I've been working with IP networks for over 3 decades. If I can't see why ouroboros is better, what hope is there for the future of the project.
Ouroboros can run over the current internet so you can reuse existing hardware, but the end goal is to get rid of TCP/IP. We have layers over L1 and L2. In lab setups we never run it over TCP/IP.
https://www.cardano.org/en/ouroboros/
https://iohk.io/en/research/library/papers/ouroborosa-provab...
Blockchain is basically an ever expanding chain (or tree if you include the shorter branches that didn't make it) so I can't understand the relation to ouroboros loop/circle.
I assume they have a different reason for naming it that but didn't ever find it.
https://www.youtube.com/watch?v=6fH23l45984
The ideas take a while to sink in but @ 1.5/2x speed it should be a quick watch and you can slow down if you hear something you like.
Hopefully they get their "marketing act together" but also it's probably unreasonable to expect that from what was once a research project and is now very early software (that I assume they are trying to commercialize/market somehow, hence the spiffy new site).
I do take "spiffy" as a compliment :)
Aaaaand you've just gained me as a lifelong fan (I mean I was already very interested) -- that's a big stand to take, and I appreciate that you guys refreshed the site & marketing materials just to get it in front of more people. I'm not in any way disappointed by your choice not to commercialize, quite the opposite in fact (as long as you guys are personally fine financially and feel comfortable contributing this work to the public domain).
You'll hear from me when I build something worth mentioning with Ouroboros!
It would be great if the site presented a side-by-side comparison of IP vs ouroboros (and had an acronym btw) for people to have a quick overview instead of digging through documentation.
(edit: and operationally you probably want to just make an overlay/tunnel network to develop your new network layer)
The fun thing is that when we compared throughput to UDP/IP, Ouroboros is a bit slower for packets below 1460 bytes, because the NIC has something called "Generic Segment Offload (GSO)" which cheats a bit and send UDP traffic as larger chunks over the kernel boundary. We have no such optimization (yet). But when we started sending jumbo frames, Ouroboros was faster than UDP/IP over Ethernet because the GSO wasn't implemented for UDP jumbo frames (not pointing fingers, nobody does that).
And this brings me to another thing. Nitpicking of course. But that is what Ouroboros is about. Picking all the nits we could find. It's one for the connoisseurs.
Ethernet has a minimum frame size that is dictated by Layer 1 and has to do with collision detection and the transmission delay/cable length. For good ol' 10 base-T it's 64 bytes. For GbE the minimum frame size for Ethernet is 512 bytes. Small Ethernet frames under 64 bytes are called runt frames. Ethernet has a length field to allow for padding.
Now the interesting part in the standards. Ethernet frames are padded to 64 bytes. But GbE ethernet frames are not padded to 512 bytes. They use something called carrier extension (and frame bursting, but let's not complicate things too much).
So there is a Layer 1 problem (minimum frame size because of cable length). The original Ethernet "fixed" this with a LENGTH field in Layer 2. While the receiver was reading the correct amount of received bytes, if it was 64, it could mean a padded Ethernet frame. Ethernet II (DIX) made things worse. The Ethernet length field is now interpreted as an EtherType, indicating the Layer 3 protocol. And the layer 3 protocol now has to have a length field to fix the Layer 1 problem. Sigh.
GbE solves it right here, right now. It does carrier extension and reports the correct amount of bytes to layer 2. But it pads to 64 bytes for compatibility.
Ouroboros' protocols have no length field. Read the details on the heartbleed bug if you want to know why this matters.
As a sidenote: Our implementation predates the Cardano blockchain name
[0] http://www.pouzinsociety.org/research/publications
The high level description could be the exact same for both. So how architecture and implementation differ?
The cleaner architecture is the whole point of the exercise.
I'm trying to avoid arguments why this would be "better" than anything else. Just some examples of things that I personally don't like about IP, and that Ouroboros does differently. These points may not matter to you, and that is perfectly fine. I'm not a salesman trying to make a sell.
1) IP (and Ethernet etc) has source addresses in every packet. Ouroboros negotiates them at the start of the communication, and only has the destination address in the packets. This improves end-user privacy a great deal.
2) The Ouroboros end-to-end protocol, (which has the RTT estimator and retransmisison timeout (RTO) timer), runs in the library between the actual server and client programs. It runs at sub-millisecond accuracy. If there is an underestimation of RTT, at worst it retransmits a few extra packets (See 3). But these improve the RTT estimate.
3) Default TCP congestion control doesn't play nice in lossy situations, having severe issues with throughput because of AIMD. Ouroboros completely splits the network and end-to-end protocol. Therefore the architecture only allows congestion control using Forward ECN at the network protocol (and only the network protocol). This is similar to the operation of DCTCP, but DCTCP has the ECN in the network protocol (IP), and the notification in the end-to-end protocol (TCP). I'm not fond of that as a solution (however, if I would run a commercial datacenter, I would run DCTCP, no doubt about that).
4) The Ouroboros end-to-end protocol is based on Delta-t, which doesn't require the 3-way handshake of TCP. It does have a two-way handshake (called flow allocation) to negotiate endpoints and the peer addresses (as to avoid sending src in every packet). But it can also do a ECDHE key exchange at that time. So it can establish an encrypted end-to-end connection in 1 RTT. The implementation still does it in 2 phases, (it's on my to-do list to piggyback the public keys).
5) Ouroboros has 2 types of layers, one for unicast and one for broadcast. This is where I think it really shines. The broadcast layer allows easy implementation of what is known as a "multicast service". A PoC is in the obc program.
Some of this may still seem nebulous, and I apologize. It's an unfunded pet project. But if I find interested people that ask interested questions, it will help me to update the documentation and make things more digestible/palatable.
Thank you again for your interest.
Does it? If someone is in a position to see the beginning of the flow, then they know both endpoints, don't they?
As another fun addition, we investigated an algorithm to distribute the actual data packets along different paths: https://lib.ugent.be/fulltxt/RUG01/002/494/958/RUG01-0024949...
No, but I would not describe it as "helping a great deal". I would describe it as "potentially help" or "help somewhat".
The two fields in the network protocol that matter are the destination address (DST) and the endpoint ID (EID). These identify the flow uniquely. I'll write this header as DST:EID.
So you find some packet that has, let's say 1000:100 as the header. Now, that flow was established at some point in the past with two packets, that are sent between components called the flow allocators. Flow allocator packets are all sent to a fixed EID, 1. So there will have been an exchange in the network of a packet with 1000:1, and a packet send back from 1000 to the source, SRC:1 (you don't know the source yet).
The contents of the first packet will be (relevant fields only) 1000:1:SRC:X with SRC the source address, and X an endpoint ID chosen by the source. When the destination receives this, it generates its EID=100 and sends the following information to the source's flow allocator: SRC:1:X:100
The source knows from X that the message is from 1000. This is enough information for both endpoints to know the <ADDR, EID> pair of their peers. An interceptor doesn't know SRC or X. You could look for all packets and find that "100" field, but how do you know it was sent by 1000?
It will take quite some traffic flow analysis to match these two packets. Probably it will be easier to try to match the actual data flows.
Now take into account that networks have multiple layers, and all flows are established this way.
It's definitely not impossible. But it's harder than just reading the first X bytes off a packet.
i like the developer focus, e.g. use the C library to write ouroboros-native programs. from a developer perspective, what types of developers for what types of use cases would benefit the most by leveraging ouroboros?
The underlying routing scheme, virtual switch/router implementation, specification etc are not aware of (nor do they care about) IP.