
Show HN: Ouroboros – A Decentralized Packet Network - despair3435
https://ouroboros.rocks
======
hardwaresofton
Ouroboros is really cool, here's their old site:

[https://ouroboros.ilabt.imec.be/index.html](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](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.

~~~
challenged
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.

~~~
hardwaresofton
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](https://youtu.be/6fH23l45984?t=1333)

[1]:
[https://youtu.be/6fH23l45984?t=1735](https://youtu.be/6fH23l45984?t=1735)

[2]:
[https://youtu.be/6fH23l45984?t=1400](https://youtu.be/6fH23l45984?t=1400)

------
jqueryin
And here I was thinking this was directly related to the Cardano project.

[https://www.cardano.org/en/ouroboros/](https://www.cardano.org/en/ouroboros/)

[https://iohk.io/en/research/library/papers/ouroborosa-
provab...](https://iohk.io/en/research/library/papers/ouroborosa-provably-
secure-proof-of-stake-blockchain-protocol/)

~~~
geoah
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.

~~~
despair3435
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.

------
firethief
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.

~~~
hardwaresofton
Please check out the FOSDEM video:

[https://www.youtube.com/watch?v=6fH23l45984](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).

~~~
dstaesse
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 :)

~~~
hardwaresofton
> 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!

------
LockAndLol
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.

~~~
convolvatron
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)

~~~
dstaesse
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.

------
slumdev
Are there any papers on this? I can only find references to the consensus
algorithm.

~~~
despair3435
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

------
still_grokking
How does this relate to GNUnet?

The high level description could be the exact same for both. So how
architecture and implementation differ?

------
dstaesse
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.

~~~
beagle3
> 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?

~~~
dstaesse
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...](https://lib.ugent.be/fulltxt/RUG01/002/494/958/RUG01-002494958_2018_0001_AC.pdf)

~~~
beagle3
> 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".

~~~
dstaesse
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.

------
drummer
I read the overview and it sounds a lot like QuantumGate
[http://quantumgate.org/](http://quantumgate.org/)

~~~
dstaesse
I looked at Quantumgate and it looks interesting :) Thanks for the pointer!

------
magdemsolrem
I'm fairly new to decentralization technology and web3, how would this relate
to let's say libp2p?

------
gz5
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?

------
bn7t
Is this similar to cjdns or yggdrasil?

~~~
despair3435
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.

~~~
neilalexander
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.

