- Joined
- Nov 5, 2018
- Messages
- 2,978
I just encountered a huge problem for some using Verizon fiber. Turns out they forgot to tell their users or resellers about this one. In reality, it shouldn't really affect users as long as you only use TCP and not UDP over their fiber. For our purposes a UDP is a data packet (data packets over Internet all have to be the same size, ~64k). A UDP packet can carry more data in that 64k because it doesn't contain much of the data used for error detection. UDP because it has less error detection travels quicker because there is no processing time doing error detection. This makes it ideal for video transmission p2p. If you have a dropped frame, no big deal.
Now here's the surprise. Verizon has implemented a data compression protocol. It consists of a codec that acts like one simple part of a video codec. You will have to admit that on let's say a facetime video call, there are moments of no movement during the call. That's where the magic begins. In both cases this means the receiver sees a series of identical or virtually identical frames. In both cases the codec senses this and rather than send a set of duplicate frames which require either more storage space or bandwidth the codec sends a small line of code that the receiver sees as "duplicate the last frame" which works because there wasn't any changes, pretty smart yes?
Sounds great except for one problem. If you try to send some TCP tagged data mixed into the stream, the codec doesn't always assemble that data correctly on the receiving end even though the codec packed it back up with the correct data tags and checksum. We were able to solve by having the receiver broadcast it only would accept TCP packets and that solved the problem. It must have forced the codec to be more vigilant.
There are the hard core guys out there who say keep the UDP confined to internetwork, but with video over the Internet becoming so popular, UDP has become very attractive.
Now here's the surprise. Verizon has implemented a data compression protocol. It consists of a codec that acts like one simple part of a video codec. You will have to admit that on let's say a facetime video call, there are moments of no movement during the call. That's where the magic begins. In both cases this means the receiver sees a series of identical or virtually identical frames. In both cases the codec senses this and rather than send a set of duplicate frames which require either more storage space or bandwidth the codec sends a small line of code that the receiver sees as "duplicate the last frame" which works because there wasn't any changes, pretty smart yes?
Sounds great except for one problem. If you try to send some TCP tagged data mixed into the stream, the codec doesn't always assemble that data correctly on the receiving end even though the codec packed it back up with the correct data tags and checksum. We were able to solve by having the receiver broadcast it only would accept TCP packets and that solved the problem. It must have forced the codec to be more vigilant.
There are the hard core guys out there who say keep the UDP confined to internetwork, but with video over the Internet becoming so popular, UDP has become very attractive.
