I am looking for a lightweight reliable protocol utilizing Ethernet jumbo frames (for instance up to 9 KBytes). One side will be implemented on an FPGA without a CPU core (so simplicity needed) and the other side on a NAS by software. Sophisticated packet routing functionality is not necessary, since it is supposed to be used in an embedded application for high-bandwidth data streaming with a very limited number of nodes. I could find the Reliable UDP Protocol by googling, but did not like the fact that it still has the full IP-Header


closed as off-topic by Ron Maupin Jul 9 '17 at 20:04

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "NE is a site for to ask and provide answers about professionally managed networks in a business environment. Your question falls outside the areas our community decided are on topic. Please visit the help center for more details. If you disagree with this closure, please ask on Network Engineering Meta." – Ron Maupin
If this question can be reworded to fit the rules in the help center, please edit the question.

  • A 20 byte "full IP-header" is about 0.2 percent of a 9000 byte packet, so I'm guessing you are not worrying about network overhead. You mention "reliable", so you would indeed be comparing your protocols to TCP or reliable UDP. The header will still be under 0.5 percent. Are you looking for a protocol to implement on an FPGA, or a usable implementation? – Gerben Dec 5 '16 at 9:52
  • A usable implementation would be of course better: I do not want to invent the wheel again. However, I can do the implementation also on my own. TCP/IP is rather heavy & complicated for the FPGA-side: That worries me more. If I can not find anything suitable, I think I will make up something new. – azdem Dec 5 '16 at 10:02
  • You really don't give enough information. For instance, does it need to be routed? Also, remember that jumbo frames are not standardized, different vendors have different implementations, they only work on the LAN, and not all switches, OSes, or host interfaces support them. There used to be LAN-only protocols, but they have been supplanted by IP because IP is lightweight and it supports LAN-to-LAN. A popular one was NetBIOS Frames protocol. I think you will find it to be more trouble than IP (chatty). – Ron Maupin Dec 5 '16 at 14:15
  • Protocol reliability equals state maintenance, which is the opposite of simple and precisely where ASIC is going to have trouble. – rnxrx Dec 5 '16 at 15:28
  • It will be used only within a LAN, (MAC Addr. based routing) Ethernet routing should be sufficient. Thanks for the replies! – azdem Dec 5 '16 at 16:52

OK - so a few points based on the comments:

1.) By definition Ethernet is not routed but rather switched, bridged or repeated.

2.) As mentioned, protocol reliability implies the ability to retransmit lost and errored frames without the interaction of a higher-layer protocol. This means that the sender and receiver will need to maintain some kind of state to track packet sequence and likely some amount of flow control to adjust based on buffering. This also means you'd need semantics for session establishment and teardown - which means timers. This is much heavier in actual practice than UDP/IP. It's also worth noting that there are lightweight/embedded IP+UDP stacks that would prevent you from having to reinvent the wheel.

3.) Take a look at the RoCE family of protocols - super low latency and supports your requirements. Interestingly version 1 of the standard runs over raw Ethernet and supports jumbo frames. Whether it hits your requirements for reliability is another question. IMO the more interesting point is that ROCEv2 has similarly excellent latency characteristics but runs over UDP (and is well-supported by a number of NIC and switch vendors). It's worth noting that part of the operation of the RoCE protocols requires lossless Ethernet facilities. Minimally this includes PFC but the spec also calls out some of the other DCB specs.

Not the answer you're looking for? Browse other questions tagged or ask your own question.