Show HN: Ouroboros – A Decentralized Packet Network(ouroboros.rocks)
ouroboros.rocks
Show HN: Ouroboros – A Decentralized Packet Network
https://ouroboros.rocks
39 comments
I want to like it for the cleaner architecture, but this site isn't helping me find reasons to do so. The FAQ seems to be the only place that "Why would I want this" is considered, and they evade a real answer. I'm sure the referenced paper supports that it's theoretically cool, but I already believe that. The only concrete benefit I see proposed is that it has a simpler API, but considering that they've punted on name resolution (for now) and async is a WIP, the API seems more complicated than BSD sockets--which everyone has experience with, has support in every language and framework, and has endless learning materials available. For a project whose value depends on a networking effect, I'm not compelled to invest energy in it until they get their marketing act together enough that I think other people might want it too.
Please check out the FOSDEM video:
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).
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'm sorry to disappoint, but we are not looking at commercializing...
Ouroboros will remain free "as in beer" and free "as in freedom".
I do take "spiffy" as a compliment :)
I do take "spiffy" as a compliment :)
> I'm sorry to disappoint, but we are not looking at commercializing... Ouroboros will remain free "as in beer" and free "as in freedom".
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!
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!
How does this relate to GNUnet?
The high level description could be the exact same for both. So how architecture and implementation differ?
The high level description could be the exact same for both. So how architecture and implementation differ?
[deleted]
I'm one of the developers. Thank you all for your interest in this project. This website is still under construction, and we're well aware that it's severely lacking in information, I'll try to find some time to update everything. Unfortunately marketing is not one of my skills.
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.
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.
You should put this up on your site as a link to "Technical Details"! For anyone who knows networking stacks, this really clarifies the features/benefits and also shows there is some substance behind the protocol/stack. Otherwise, like everyone else pointed out, the web-site itself doesn't provide a clue as to why one would use this.
> only has the destination address in the packets. This improves end-user privacy a great deal.
Does it? If someone is in a position to see the beginning of the flow, then they know both endpoints, don't they?
Does it? If someone is in a position to see the beginning of the flow, then they know both endpoints, don't they?
Sure. It's an odds game. But, do you have a counter-example where sending the source address in every packet has better privacy than not doing so?
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...
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...
> But, do you have a counter-example where sending the source address in every packet has better privacy than not doing so?
No, but I would not describe it as "helping a great deal". I would describe it as "potentially help" or "help somewhat".
No, but I would not describe it as "helping a great deal". I would describe it as "potentially help" or "help somewhat".
Well, fair enough. Let me explain a bit how it would be done. Finding the "first packets" is not as easy as you may think.
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.
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 read the overview and it sounds a lot like QuantumGate http://quantumgate.org/
I looked at Quantumgate and it looks interesting :) Thanks for the pointer!
I'm fairly new to decentralization technology and web3, how would this relate to let's say libp2p?
And here I was thinking this was directly related to the Cardano project.
https://www.cardano.org/en/ouroboros/
https://iohk.io/en/research/library/papers/ouroborosa-provab...
https://www.cardano.org/en/ouroboros/
https://iohk.io/en/research/library/papers/ouroborosa-provab...
Something that always bugged me with cardano's Ouroboros is the name. Ouroboros means eating (usually your own) tail, and the symbol that usually goes with it is a snake/dragon as a loop/circle.
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.
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.
We chose Ouroboros since there is a single type of network layer that can be repeated ad infinitum, similar to the dragon eating its own tail.
I understood it to be that Ouroboros went around the world? And Jormungandr is a type of Ouroboros (the Rust implementation of Ourorboros).
Ouroboros is really cool, here's their old site:
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.
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.
But what problem does it solve? How is it better than what we have? What are the practical uses? What is a concrete example of the benefits?
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.
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.
This is one of those things you really have to watch the video or understand the concept to have it spark your brain (or not). Here's a timestamped link to the part of the video I think is interesting[0].
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
[1]: https://youtu.be/6fH23l45984?t=1735
[2]: https://youtu.be/6fH23l45984?t=1400
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
[1]: https://youtu.be/6fH23l45984?t=1735
[2]: https://youtu.be/6fH23l45984?t=1400
Same here..
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.
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.
Hi, i watched the video but they didn't seem to talk about something i would find important in the description of a packet network: what's the routing algorithm? Is there actually any? If this is meant to run large-scale only on top of some ip network using already configured routing tables then this lowers the interest a lot for me: this ends up "just" being another overlay network, albeit with cool concepts and pretty adaptable tunneling possibilities.
The routing algorithm can be chosen in every layer, as addressing is per layer. We didn't reinvent the algorithms. So it would still be link state, distance vector, geometric routing, ... Since the addressing is internal to the layer, you probably won't have the same issues with geometric routing as currently in TCP/IP.
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.
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.
If there were an internet what routing algorithm would it use?
As the previous commenter stated, since you can choose the routing algo at every layer, you could completely reproduce the current internet -- or choose to implement something better on some axis.
Is this similar to cjdns or yggdrasil?
No, Ouroboros rethinks the whole network architecture, from the ground up. cjdns and yggdrasil build on top of IPv6, which we believe has the same architectural flaws as IPv4.
For accuracy, Yggdrasil doesn't "build on top of IPv6", it merely uses IPv6 over TUN in the current binaries because that most closely translates to a usable experience for real people today without having to rewrite their applications. It has been a good way to get users to help scale-test.
The underlying routing scheme, virtual switch/router implementation, specification etc are not aware of (nor do they care about) IP.
The underlying routing scheme, virtual switch/router implementation, specification etc are not aware of (nor do they care about) IP.
Isn't IP implemented at the hardware level nowadays? Is it still possible to buy any consumer-grade network hardware that allows to replace IP?
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.
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.
there may be various kinds of accelerations...but it pretty much has to be possible to send and receive ethernet frames
(edit: and operationally you probably want to just make an overlay/tunnel network to develop your new network layer)
(edit: and operationally you probably want to just make an overlay/tunnel network to develop your new network layer)
In most of our Ouroboros deployments (meaning: in the lab) we did just that. We use a raw packet interface (bpf on mac, raw sockets on linux) and send Ouroboros traffic on top of Ethernet.
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.
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.
Are there any papers on this? I can only find references to the consensus algorithm.
We have a paper under review (since a year) describing the architecture in detail. We plan to extend the documentation on the website in the meantime.
As a sidenote: Our implementation predates the Cardano blockchain name
As a sidenote: Our implementation predates the Cardano blockchain name
Can't find anything either, not sure if there is. On the other hand, they seem to reference research done around "Recursive InterNetwork Architecture" (RINA). Publication page is at [0]. Maybe also of interest some other RINA implementations: [1], [2].
[0] http://www.pouzinsociety.org/research/publications
[1] https://irati.github.io/stack/
[2] https://github.com/rlite/rlite
[0] http://www.pouzinsociety.org/research/publications
[1] https://irati.github.io/stack/
[2] https://github.com/rlite/rlite
very promising - looking forward to digging in and seeing the architecture.
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?
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?