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