<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 30, 2016 at 1:24 PM, Juliusz Chroboczek <span dir="ltr"><<a href="mailto:jch@pps.univ-paris-diderot.fr" target="_blank">jch@pps.univ-paris-diderot.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 300 bit/s is tough... even sending an empty IPv4 UDP packet would normally<br>
> cost 14+20+8=42 bytes, which block a channel like this for more than a<br>
> second.<br></span></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>You'd probably need header compression, perhaps combined with link-layer<br>
fragmentation.  I'd look at ROHC, 6lowpan, and perhaps some of the work of<br>
the RPL crowd (not the RPL protocol itself, which is overkill in your case<br>
since you have plenty of RAM and CPU power, but their experiences with<br>
low-throughput links).<br><br></blockquote><div>ROHC for multicast is always a bit tricky, but doable... would reduce the overhead of IP and UDP to 3 bytes.</div><div><br></div><div>Henning </div></div><br></div></div>