Slashdot Mirror
Ethernet Consortia Wants To Unlock a More Time-Sensitive Network (networkworld.com)
Does Ethernet need new features like "stream reservation" and time synchronization to make sure time-sensitive data isn't delayed on the network? coondoggie quotes Network World: The demand from Internet of Things, automotive networking and video applications are driving changes to Ethernet technology that will make it more time-sensitive. Key to those changes are a number of developing standards but also a push this week from the University of New Hampshire InterOperability Laboratory to set up three new industry specific Ethernet Time-Sensitive Networking consortiums -- Automotive Networking, Industrial Networking, and ProAV Networking aimed at developing deterministic performance within standard Ethernet for real-time, mission critical applications. "Standards-based precise time, guaranteed bandwidth, and guaranteed worst-case latency in a converged Ethernet network is a game-changer to many industries," said Bob Noseworthy, Chief Engineer, UNH-IOL.
The article also acknowledges the work of the Avnu Alliance, which is also trying to build an ecosystem of "low-latency, time-synchronized, highly reliable synchronized networked devices using open standards through certification."
The article also acknowledges the work of the Avnu Alliance, which is also trying to build an ecosystem of "low-latency, time-synchronized, highly reliable synchronized networked devices using open standards through certification."
Dear Internet of Things,
First, fix your damned security problems. Then we'll talk about your "demands".
Sincerely,
The rest of the internet
Irony: Agile development has too much intertia to be abandoned now.
Because of the multitude of fuckers that'll simply abuse it by releasing 'get your internet faster' programs which'll blanket-prioritise every fucking thing.
It's about time - I keep running into issues with my IoT botnets, car overrides, and industrial process control malware where I just can't guarantee that I can get into these hideously insecure systems on a fixed time budget.
This is a serious concern, because when I can only deliver 500,000 insecure baby monitors to my Russian masters instead of the 800,000 they demanded, that's a polonium-210 desert!
(Seriously, this is actually a real issue that needs to be fixed- you want real-time ethernet for some things like you want a real-time kernel, but I can't help picturing this as working on how reliably you can get across a flaming bridge).
Networks aren't deterministic, so any protocol has to handle lost and delayed frames anyway. There is very little benefit to the complexity of low level traffic management, compared to using a simpler design and just adding more bandwidth. The internet is a "dumb network, smart edge" design, and it left "smarter" network designs in the dust for a reason.
It's the wrong layer to do "stream reservations" or any such kind of prioritising. Ethernet is supposed to deliver bits and frames as-is, managing buffers or the order of packets belongs to a higher layer. Such a layering violation results in no end of bloat and complexity. Complexity = errors.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
"Does Ethernet need new features like stream reservation" ? This only happens when certain companies are looking for an excuse to band width throttle their part of the internet. A personal reflection is that if these grinning show offs don't like it; they can always walk away.
Ethernet works well if you have over-provisioning. It is simple, almost zero-configuration, robust and reliable. This really bad idea would destroy all these characteristics. Why some (really bad) engineers cannot stay the hell away from things that work well is beyond me.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
We need fixed latency low overhead transfers. Open a pipe and just feed data into it. If the network has the bandwidth it will open a channel through the network, all the switches and routers along the route would dedicate a time slice to that exact pipe.
Essentially it means your socket is guaranteed at least 1 packet every n time units. Back in '01 I worked for a startup that had a wireless chip with isochronous features. I wrote the device driver and trust me, when you have more than 1 isochronous stream it can get pretty hairy to ensure both stream's needs are met.
The hardware worked, but pulled too much power. They ran out of money before they could so another chip spin. Kinda sad, it was pretty impressive for the time.
> > We need fixed-bandwidth, low-latency
> so ... UDP
UDP provides neither fixed bandwidth nor low latency.
UDP, as opposed to TCP, simply says that a packet is processed whether or not some previous packet went missing, and no mechanism is provided for recovering lost packets. It's useful when you don't want to resend lost packets because they'll be outdated anyway, such as VoIP.
Referring to TFS:
--
Standards-based precise time, guaranteed bandwidth, and guaranteed worst-case latency
--
UDP doesn't do any of that either.
> No it is not enough.
> Some application need absolute guaranteed (provable) latency,
> use static bandwidth allocations, make the switches ensure that
> the endpoints respect that allocation even in case of failures, etc.
> For SAFETY.
In that case, they need their own dedicated network. The public internet cannot guarantee a packet gets from Point A to Point B, let alone gets there in a specified time. All this does is provide an excuse to throttle "less important traffic", i.e. any website that doesn't pay greedy ISPs for higher priority.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
First of all, please define "we"... I'd love to identify an industry where this makes sense ... I'm not seeing it.
I developed real-time low latency, low jitter broadcast video codec hardware for years. The codecs I developed were layer 1-7 codecs meaning that I counted clock cycles inside the FPGA implementation of the Ethernet MAC as I was designing the compression mechanism to reduce encoding and decoding latency to ridiculously low amounts. I also worked as a protocol developer at one of the largest video conferencing companies in the world where I spent a year on clock synchronization through RTP and RTCP. I currently am a network engineer (I sold out for the money) where I regularly am called in for designing end-to-end real-time QoS from app, through nic to switch etc... I focus on all layers, not just the network or app.
I have never imagined a scenario where this technology would be useful.
You don't need NTP or PTP for clock synchronization in two way communication. Only when there is a single streaming device. If an industry thinks they need this, they probably are trying to solve a problem with the algorithms at the physical layer. That said, Ethernet is absolutely the dumbest technology to use for these things.
1) Ethernet is attractive because of cheap cable and you can buy it anywhere.
2) Ethernet won the network war because it was cheap and because.... nope that's it. It was cheap but mostly crappy. To this day, with the exception of things like TRILL and ACI type networking, we treat all Ethernet networking as a bunch of coax cabled plugged in together. And even then, the clients generally don't talk to the switches. It's a spray and pray protocol.
3) Real-time standards on Ethernet requiring upgrades to the networking switches are extremely expensive. This is contrary to the "keep it cheap" mentality of Ethernet. Everything that makes this idea attractive goes to hell the moment you realize that deterministic latency within an Ethernet ASIC requires a whole new ASIC to achieve TDM like behavior. Also consider the logic required to design time-slots into something like Ethernet. Every packet before being sent will have to be calculated for "streaming time" and possibly delayed because the TDM packet may have to transmit in the middle of it's "slot".
4) Ethernet is layer-2, it's local premises only and has almost no possible value because even on local premise, layer-2 doesn't scale. If you add it to TRILL, what in the name of hell are you really trying to accomplish?
Let's consider automotive applications...
Fix the f-ing problem don't perpetuate CANBUS nonsense for no reason. There is absolutely not a single clock in the entire vehicle that requires better resolution than can be had from NTP. In addition, industrial ethernet has to be the dumbest frigging idea in the history of man. CANBUS was great when there were a handful of systems in the car and SoCs were not practical. These days, Atmel, Microchip, etc... can ship $2 automotive grade chips with pretty much any physical interface on them. CANBUS is basically crap by modern standards. Consider BMW whose entire in car experience is buggier than all shit because they insist on sticking with CANBUS bullshit. Make a new CANBUS alternative... quit trying to use Ethernet in the car... it is now and always will be the wrong choice. Automotive must be the absolute last place Ethernet has application.
Industrial networking...
This one is easy. From lots of experience in this case... Industrial Ethernet is absolutely shit. If you're looking for a replacement for RS-485 networking, this isn't it. In addition, this kinky CANBUS over Ethernet thing is just a disaster waiting to happen. I was working in a paper mill and asking "Why are you replacing RS-485 with Ethernet?" and the answer was simple... "Cisco told us it was better". There are cases like bottle inspection plants where higher speed could be useful but if you're de
Jeez, and I was just clicking into this article to post a sarcastic remark that ethernet was finally coming full circle from beatng out ATM, to becoming ATM, just like IDE/ATA became SCSI and USB is becoming firewire. Now I find I've been totally out-bus-protocol-geeked. Thanks for the interesting read.
Someone had to do it.
The problem is you can't just add more bandwidth.Cheap networking is 1Gbit now, but if your streaming needs are starting to chew up a significant proportion of that, it's no longer an option. This is especially so when your devices may be embedded and can't actually handle full Gbit networking.
So you may be able to do a couple of 100Mbit streams (not hard - Blu-Ray disc streams average 25-40Mbps and peak to 100Mbps, UHD Blu-Ray is closer to twice that). But if your device can only do day, 300Mbps then you can do one stream, two streams is pushing it. And if you have extra traffic on the network then your hardware no longer can process the video stream it's supposed to because it's now busy handling the other traffic, so what you end up with is a stuttery mess.
And yes, it has happened, the only solution being to VLAN or isolate the affected network components
And this happens because the device has to process every packet.
First thanks for that first line of text. I like many often use Slashdot as a place to be a jerk and when I do take the time to "say something productive" it's nice to have it noticed.
HDBase-T is almost exactly what I was talking about. Before I sold my soul and left computer science for the more lucrative world of IT, it hadn't evolved yet and looked to be purely a consumer standard. Cat-5e has some hard limitations. It has a rated frequency bandwidth of 100Mhz while Cat6 is rated for 250Mhz. Standard definition video for SDI transmits as 270Mhz and HD-SDI at 1.485Ghz, and then it doubles for each step including 3GSDI, 6GSDI and 12GSDI. Even considering low balancing of TDM cells across 4 pairs, LVDS (the preferred modulation of twisted pair), only about 2/3 of the HD-SDI signal can cross a Cat6 link.
This means that to achieve better performance OFDM, QAM and other modulation must be considered to carry more bandwidth on this links. I'I not a physics expert, but purely through speculating I would imagine at least a theoretical SNR loss over distance.
It appears that HDBase-T is supposed to transmit at 10.2Gbit/sec which would suggest 4 parallel 2.55 Gbit/sec links through common Cat5e or Cat6. To be conservative, this could be 16QAM with some error checking but I haven't read the spec close enough to do more than speculate.
Either way, the modulation is less interesting than using Cat5e and Cat6 as a layer-1 medium for carrying HDMI.
This means :
A) the modulation is not compatible with Ethernet transceivers.
B) It'a probably a huge step in the right direction but not quite perfect.
The 2.0 spec appears to have been designed to carry 4k30p video. Ideally, we would go 8k60p which will require 8 times the bandwidth. This is realistic using 100Gbit SFPs in the future.
4k30p can be done reliably today using 10Gbit SFP+ modules. They cost approximately $30 each from the right vendor. An FPGA capable of converting HDMI or 6G-SDI to function on the SFP+ PHY probably costs another $20-$50. This would allow bidirectional studio quality video at 2K60p or 4K30p.
I feel like I'm writing a book. HDBase-T is probably the best current standard for carrying studio video without "Ethernet MAC problems". It's still a few generations off from being a real replacement for SDI and TDM oriented technologies.
It's genuinely weird being out-slashdotted by someone with a UID that has more digits than you. Gives me hope for the future.
Physics is nothing like religion. If it was, we'd have an easier time trying to raise money!