Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RaptorCast: Designing a Messaging Layer

category.xyz

Post reply on HN
Print view View original

11–16 of 16 posts

Re: RaptorCast: Designing a Messaging Layer

#11

Post by lxgr »

simcop2387 wrote: post #7
PhilipRoman wrote: post #6

Earlier quoted context omitted.

It's a shame because the datagram paradigm is so much more elegant. In real world cases you end up having to emulate it by putting length prefixed data in TCP streams, reducing TCP timeouts, constantly reconnecting sockets (with the latency penalty), etc. Really, the only thing that's missing from UDP is (optional) backpressure. A lot of software can handle out-of-order datagrams with no performance penalty (like fil…

This is one reason that I'm still upset about the failure that SCTP has ended up. It really did try to create a new protocol for dealing with exactly all of these issues but support and ossification basically meant it's a non-starter. I'd have loved if it was a mandatory part of IPv6 so that it'd eventually get useful support but I'm pretty sure that would have made IPv6 adoption even worse.

As long as you're fine with UDP encapsulation, you can definitely use SCTP today! WebRTC data channels do, for example.

Re: RaptorCast: Designing a Messaging Layer

#12

Post by Veserv »

simcop2387 wrote: post #7
PhilipRoman wrote: post #6

Earlier quoted context omitted.

It's a shame because the datagram paradigm is so much more elegant. In real world cases you end up having to emulate it by putting length prefixed data in TCP streams, reducing TCP timeouts, constantly reconnecting sockets (with the latency penalty), etc. Really, the only thing that's missing from UDP is (optional) backpressure. A lot of software can handle out-of-order datagrams with no performance penalty (like fil…

This is one reason that I'm still upset about the failure that SCTP has ended up. It really did try to create a new protocol for dealing with exactly all of these issues but support and ossification basically meant it's a non-starter. I'd have loved if it was a mandatory part of IPv6 so that it'd eventually get useful support but I'm pretty sure that would have made IPv6 adoption even worse.

Well we have QUIC now which layers over UDP and is functionally strictly superior to SCTP as SCTP still suffered from head-of-line blocking due to bad acknowledgement design.

Re: RaptorCast: Designing a Messaging Layer

#13

Post by compyman »

yangl1996 wrote: post #8

Looks like there is no mentioning in the blogpost of the paper (poster) [1] in which the two-level broadcast idea is proposed. [1] https://dl.acm.org/doi/pdf/10.1145/3548606.3563494

It seems very similar to an earlier paxos optimization called 'pig paxos' https://dl.acm.org/doi/10.1145/3448016.3452834

Re: RaptorCast: Designing a Messaging Layer

#14

Post by klabb3 »

PhilipRoman wrote: post #6
klabb3 wrote: post #3

> Assuming zero network latency and a bandwidth of 1 Gbps, this would still take around 16 seconds I’m not seeing how the new design affects the throughput needs, but I’ll say this: Except for highly controlled environments (OS, NICs etc), you will run into perf issues with UDP-based protocols much sooner than with TCP, even if you’re just pushing zeroes. Packet switching is much more difficult to optimize. If you on…

It's a shame because the datagram paradigm is so much more elegant. In real world cases you end up having to emulate it by putting length prefixed data in TCP streams, reducing TCP timeouts, constantly reconnecting sockets (with the latency penalty), etc. Really, the only thing that's missing from UDP is (optional) backpressure. A lot of software can handle out-of-order datagrams with no performance penalty (like fil…

Agreed but I think it’s better to use streams and deliver messages reliably and in order today, despite the extra effort.

For instance, TLS is stateful. If you want to deliver unannounced (stateless) datagrams to a server, you’d technically be able to use the servers pubkey but you’d have to sacrifice forward secrecy. Making business logic with dropped packets and OOO delivery is also very difficult depending on domain.

Personally I would like to see faster bootstrap and especially resumes of streams to eliminate handshake cost. For instance:

- resume with last shared secret for 0rtt handshake (I believe Quic supports this)

- allow the dialer to queue/send data before ack (this is an API-breaking change on sockets, but worthwhile imo - it makes socket FSM on app layer easier to use because it never needs to be nil

Re: RaptorCast: Designing a Messaging Layer

#15

Post by toolslive »

> If peeling fails, R10 falls back to solving the system of equations using Gaussian elimination.

I've built a decoder for online codes (very similar) in the past and learned that it's best to just to a Gauss elimination step regardless of the degree of equation/packet/message you get. Also, since the system is very sparse it's best to not have a matrix representation, even if you're using bitvectors, as you'll be scanning rows which have mostly zeros. Just use a representation for sparse sets.

Anyway, just my 2cts

Re: RaptorCast: Designing a Messaging Layer

#16

Post by addaon »

tklenze wrote: post #4
klabb3 wrote: post #3

> Assuming zero network latency and a bandwidth of 1 Gbps, this would still take around 16 seconds I’m not seeing how the new design affects the throughput needs, but I’ll say this: Except for highly controlled environments (OS, NICs etc), you will run into perf issues with UDP-based protocols much sooner than with TCP, even if you’re just pushing zeroes. Packet switching is much more difficult to optimize. If you on…

Thanks for your insights! Yes, real-life behavior is indeed interesting to look at, and for this purpose, two testnets are running right now ( https://www.gmonads.com ). RaptorCast uses erasure coding to break a block proposal into smaller pieces with plenty of redundancy to allow for omissions. This means that if you receive sufficiently many chunks, you can decode the block proposal (no matter which of the chunks y…

> If you have 100 peers and one of them is too slow, what are you going to do?

Detect, and remove them from the set, so that if the bottle-neck is upstream of them you're relaxing pressure on switches etc that may be shared with nearby nodes, reducing the chance that two of them are suddenly too slow...

Post reply on HN