Hacker News new | past | comments | ask | show | jobs | submit login
Ouroboros: Distributed System for Packetized Network Communications (ouroboros.rocks)
41 points by signa11 on Dec 14, 2021 | hide | past | favorite | 10 comments



I wish the website listed concrete differences compared to TCP/IP, QUIC, SCTP, and UDP. Without specific details I'm not sure why one would choose Ouroboros over existing solutions.


More efficient transit of data over a network is one reason. Protocols like ethernet have specific length constraints, introducing padding and parsing stages that increases latency and resource use.

One of the developers posted the following in a previous hn thread:

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.


What platforms does C library support ?


Thanks for sharing!


That’s a confusing name considering it’s already taken by a family of consensus protocol https://en.wikipedia.org/wiki/Ouroboros_(protocol)?wprov=sft...


Even more confusing considering that the Ouroboros you linked is also a distributed system, and consensus is based on network communications.


Since the plural of ouruboros seems relevant, here if almost nowhere else: https://www.ouruboroi.com


Also: a ransomware variant


One past thread:

Show HN: Ouroboros – A Decentralized Packet Network - https://news.ycombinator.com/item?id=22052416 - Jan 2020 (38 comments)


Interesting but it doesn't look very active.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: