3

For the sake of the argument, let's talk TCP/IP, but if other technologies are more suitable, by all means, please say so!

My understanding of classic link aggregation is a round-robin type send method for combined bandwidth and ideally line-level redundancy on whichever layer.

Is there a method for bonding two connections, which mirror the data sent and uses the mirrors for real time error correction? Maybe even through checksums instead of full multiplication? Think "raid for networking".

This would be useful to add error correction to applications, which do not offer it themselves. One example would be VoIP over wireless networks, which often suffers from late or lost packets.

  • 1
    What you want is not ethernet. There are numerous layer-1 and 2 systems that (a) have error correction, and (b) can support parallel transmit. The issue with ethernet is the lack of any individual frame id. – Ricky Beam Jan 21 '16 at 20:14
  • Ethernet is the lowest level where this would be useful in my specific case. It would make most sense on the IP level. – Someone Jan 24 '16 at 16:28
  • 1
    Generally, duplicate traffic on a network is considered anathema, and sending round-robin can create problems with the transport layer which can really mess up real-time traffic since TCP can deal with out-of-order reception, but UDP, which real-time uses, cannot. As I previously commented, you are perfectly free to submit an RFC for approval. You may even want to join IEEE so that you can propose this to the 802.3 group. Unfortunately, outside of custom, I don't think you are going to find what you are looking for. This is not the place to vent for perceived standards shortcomings. – Ron Maupin Jan 24 '16 at 20:23
1

Have I heard of such a system? no Could such a system be built? absoloutely!

An obvious simple method would be to give each packet an ID number in your "expander". Then in your "contractor" you check if the sequence number has already been received. If it hasn't you de-encapsulate the data. If it has you drop the data.

Linux provides "TUN" and "TAP" interfaces which let you create virtual network interfaces from userspace so it shouldn't be too hard to whip up a prototype of such an idea.

| improve this answer | |
  • The original question, which almost all the comments and answer addressed, specifically mentioned ethernet, and the OP was looking for an existing standard which he couldn't seem to find. You can look at what was originally written by clicking on the edited Jan 24 at 16:42 link. – Ron Maupin Feb 24 '16 at 3:54
  • I tried to define a common ground instead of making this about a specific layer, so suggestions remain realistic. Apparently that intention backfired. :) Wrapping the data is a great idea! – Someone Feb 24 '16 at 14:37
  • Well there is nothing stopping you doing IP over ethernet over custom redundant tunnelling protocol over UDP over IP over ethernet if you so desire. – Peter Green Feb 24 '16 at 14:51
1

Ethernet doesn't provide anything like what you are describing; there just isn't any error correction in ethernet. Error correction is left to upper-layer protocols, which may or may not have any error correction.

Redundant traffic flows actually cause problems in the network stack, and they use unnecessary bandwidth.

In general, when errors are detected, such as a bad ethernet FCS (CRC), it is better to discard a bad datagram (frame, packet, segment, etc.) as soon as possible so that the upper layers will miss it and ask that it be resent.

Round-robin is usually a bad idea since it can cause problems for upper-layer protocols by increasing the out-of-sequence datagrams. A better method is to use some sort of hashing so that a single data stream uses only one of the links (spread the data streams across the links).

| improve this answer | |
  • I'm not really looking to do this in a specific way or on a specific layer, I just tried to set a common ground, because for example a valid answer involving token ring would be very interesting, but probably not useful. :-) I know that physical Ethernet links can be aggregated through port trunking, for example, but to my knowledge that's only a round robin thing. Of course, error correction always adds inefficiency, but in this case the speed of the correction is of the essence, so regular TCP resends unfortunately won't suffice. The IP layer feels like a good place for such a thing. – Someone Jan 21 '16 at 17:01
  • You can bond ethernet links, but there are several defined modes. Round-robin is one of several modes, but it is not recommended since it can increase out-of-sequence datagram delivery. Ethernet, and many networking protocols, purposely put in error detection without error correction. IPv6 has even dropped error detection altogether because layer-2 and layer-4 do it. There are very many extremely smart people who do nothing but think about this stuff all day, every day. If there is a compelling reason to do what you describe, someone (even you) would/could propose a new RFC for approval. – Ron Maupin Jan 21 '16 at 17:09
  • The compelling reason is quite simple: Any application, which relies on real time data, but does not implement error correction itself. In my specific case it's VoIP, but I could see it being useful for gaming and similar things. Especially mobile and some consumer Internet connections can be extremely unreliable. I know of a proprietary system, which sends data over several mobile networks and just uses whichever packet arrives first. That's a brute force way. Some audio codecs offer forward error correction. I wonder if there is a generic method on whichever layer. – Someone Jan 24 '16 at 16:38
  • Let's forget the Ethernet, that makes no sense. I'll edit the question. – Someone Jan 24 '16 at 16:38
  • 3
    If you receive two VoIP packets, and they are different, how will you tell which is correct? – Ron Trunk Feb 23 '16 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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