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."
Like in IEEE1588 aka PTP?
I mean, that's what makes voice traffic work over a congested link.
Reinventing the wheel, yet again, why oh why do we keep doing this?
I mean ISO 17458-1 to 5.
FlexRay supports high data rates, up to 10 Mbit/s, explicitly supports both star and "party line" bus topologies, and can have two independent data channels for fault-tolerance (communication can continue with reduced bandwidth if one channel is inoperative). The bus operates on a time cycle, divided into two parts: the static segment and the dynamic segment. The static segment is preallocated into slices for individual communication types, providing a stronger real-time guarantee than its predecessor CAN. The dynamic segment operates more like CAN, with nodes taking control of the bus as available, allowing event-triggered behavior.
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.
Yeah sure, let's make each packet even more bloated than they already are by adding more layers of shit to it that has to be transmitted and handled at either end, great idea.
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.
"Consortia" is plural. So Consortia agrees with "want", not "wants".
Even worse, the original submission was correct, so you went out of your way to make it incorrect. That takes dedication to bad English.
The real "Libtards" are the Libertarians!
Technology from the dark ages of networking to support the return of the Dark Ages in the USA.
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.
If you want token ring, you know where to find it. Ethernet is not that. If you want that, you're far better off just reinvigorating a token ring standard and having at it.
I designed a routing protocol way back in 2000,
and it did ALL of this, and MORE.
its almost 17 years later, and NO routing protocol has even come close.
They say we're 10 years away from something coming close to something I achieved almost 20 years ago.
And, the kicker is, no one cares.
So keep you crap new ethernet, your crap IPV6 garbage, and crap routing protocols.
The future was here, and you've ignored it.
I think there's a Van Jacobsen article about that (;-))
davecb@spamcop.net
If you're going to use a plural like 'consortia', following it with 'wants' is a bit retarded.
Why re-invent the wheel? Dump ethernet and convert everything over to token ring.
btw. Give me a ring when you finally dump token ring and convert everything over to ethernet.
I vaguely recall TTP being discussed. Here is, presumably, a good link to it:
TTP
Both this and the slashdot linked article mention time sensitive networking. Some of the tttech's summary follows. I do agree that some standardization is required such that in many cases latency guarantees can be made, since without latency guarantees you can't do anything safety critical with it. Ethernet is just too nice not to be able to use it for real time applications and instead to be forced to use some older barely functional crap just because determinism is provable.
From the link:
Deterministic Ethernet refers to a networked communication technology that uses time scheduling to bring deterministic real-time communication to standard IEEE 802 Ethernet. Deterministic Ethernet operates using a global sense of time and a schedule which is shared between network components.
By using Deterministic Ethernet customers can converge real-time controls traffic with regular best effort traffic on one Ethernet network. Time-scheduled traffic is partitioned from all other network traffic and is therefore immune from disturbance. This means that in a Deterministic Ethernet network, latency of critical scheduled communication is guaranteed. This is called Guarantee of Service.
Deterministic Ethernet is used in a wide range of applications where guaranteed latency is vital, either for reasons of operational efficiency or functional safety. These include autonomous driving, machine-to-machine communication and aerospace flight control.
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.
Let me get this straight. the ultimate destruction of the net is to be accellerated by giving the Internet of Things top priority? I realize that the world has gone batshit insane, but this is like giving Pedophiles guaranteed and first access to your children. Sorry honey, but Jerry Sandusky need to see little Timmy for personal hygeine lessons before we can give him breakfast.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
The IETF has done this before. ST-II, documented in RFC1190. Technically it is IPv5. I documented an even better protocol, at the link layer, in RFC2549.
I recall a quote that is perhaps falsely attributed to Henry Ford and it's something like, "If I had asked people what they wanted they would have said a faster horse." Ethernet does what it does because of it was made within the confines of the needs of a particular base of users. This is a different need and instead of creating a "faster horse" that might break the standard, cause incompatibilities, and other problems I believe they should simply start over with something new, a spec that wouldn't try to fit in the confines that may no longer apply.
I think that if they want to extend a standard to get a time sensitive network then they should look at something besides Ethernet. Firewire comes to mind, it's a standard that had time sensitivity from the start. Other possible standards could be USB-C, PCIe/ThunderBolt, or even extending some A/V protocol like DisplayPort or HDMI. I recall a certain protocol used in aircraft for sending critical data but the name escapes me at the moment, use that.
Maybe "faster horse" isn't the right analogy but instead call it a "camel", a horse designed by committee.
I am armed because I am free. I am free because I am armed.
Love, people with common fucking sense.
Get your shit designed to internetify everything so that the nsa can monitor every fucking step we take and every thing we do out of our fucking lives. You are a bunch of shitheaded fucks that need to die off so the world can go back to normal.
Take your internet of spying, erm, things, and get the fuck out. And while you're going, take the goddamn smartphone clusterfuck spy network with you. I want my fucking privacy back.
There already are packet switching tech with ability to "handle both traditional high-throughput data traffic, and real-time, low-latency content such as voice and video." call ATM.
To fix Ethernet's high jitter delivery, the frame size need to be small and fixed. Doing so it will not longer be Ethernet.
If we keep the 64-1500byte Ethernet frame, frame delay will be variable and long, real time traffic cannot be guaranteed.
Why reinvent a square wheel if all problems has been tackled by ATM?
> > 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 you didn't because a _routing_ protocoll cannot do these things.
> 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
Dear EditorDavid:
If you're going to claim to be an actual editor, it would behoove you to learn the basics of English grammar. The rule is: one actor wants, multiple actors want.
In this case, the word "consortia" is plural in form, so they "want." It's subtle, I know ... but, if you'd prefer that people who care about language and communications (you know - writers, professional editors, and educated readers) not laugh and point when your byline appears as the editor of stories posted to slushdot, you really should learn and apply that rule.
Just as importantly, your headline claims that it's " Ethernet consortia" that are expressing this desire, whereas the body of the article makes it clear that it's actually the New Hampshire InterOperability Laboratory that wants this, since it's the party that's trying to push for it. So, the headline is not only grammatically incorrect, it's factually challenged, as well.
Welcome to Slashdot ...
Check out my novel.
https://en.wikipedia.org/wiki/EtherCAT
People are fucking stupid as shit. Fuck people.
You want synchronous networking for the fucking "IoT"?
Fuck me. What a joke.
1) IoT exists because of price
2) Ethernet is cheap. Wifi is cheap. I can't imagine something synchronous will be even close to economical.
3) Ethernet works well when over provisioned.
4) fuck you, that's what. You cunt.
Seriously, we do need this. There was a push for synchronous Ethernet many years ago. Nothing happened. However, it's wrong to do this for IoT. It's more warranted for applications like voice, video, etc.
But, fuck IoT.
So is the effort an expansion of the 802.1Qat for other markets? Are the AV people dissatisfied of 802.1Qat, or is it not readily available in the market?
Time goes on. Then ancestors of the original designers will likely decide to play around with new ideas, or even applying very old ideas to an environment with variously changed facets.
If China was willing to admit that the 'one child' policy was a 'big mistake', I'm willing to admit that the world might do well for a few decades with each country having it's own 'smart' 'great firewall'. Blindly letting all traffic in from regions where you have no legal recourse does seem likely to have undesired consequences.
It would change the tradeoffs for the new experimental parts. Those experimental parts would end up being deployed where that change in tradeoffs would be beneficial.
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.
Geofence out the USA - save the world from Trump
If you need all that, use ATM. Ethernet is meant to be a low cost technology for the vast majority who don't need those features.
building 7 is the key to unravel the truth of 9/11
The problem is you can't just add more bandwidth.
Mod up! You could have stopped right there.
Sweet Jeebuz, so many people think that bandwidth is somehow infinite.
And every techno-zealot seems to want to dump everything else for their pet projects. I mean who wouldn't want an app for their smartphone that controls their window blinds? https://www.hunterdouglas.com/... I like how the woman is standing right in front of the window.
Its kinda scary that someone somewhere thinks that is the priority use of teh intertoobz.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Wasn't ATM (Asynchronous Transfer Mode) designed to address this kind of requirement?
1588 aware switches already fix the issue of precision time distribution with (near?) commodity ethernet switches. (see 1588 boundary and trnasparent clock modes)
Looks like for the predictable packet forwarding behavior, the Bell heads (TDM folks) just won't give up.
In the statistical multiplexed packet area, there are 3 ways to skin the cat.
(State at the endpoints)
If you control the packet load at the higher priority levels to prevent congestion you get a reliable, predictable network with low latency.(see CAC and RSVP)
(State in the middle)
If you put in precision per-customer queueing and scheduling at every switching point, you get the same. (see ATM, and please don't do that again)
(State in the packets)
If you tag the packets with how they are behaving with respect to their traffic contract and put logic at each switching point to only pass the most behaving packets during congestion, you get the same. (see rainbow queueing)
Aside from more bits per second, I'm not sure what the Ethernet standards folks can do to add to this party?
Packet preemption would help making priority packets PDV, especially with jumbo frames. This might be reasonable is it does not come with too much other baggage. IE, it just works in networks with existing Ethernet switches and traffic.
RSVP seems the domain of things that run on top of Ethernet.
ATM seems the opposite of the main draw for Ethernet. (Cheap, commodity hardware.)
The rainbow stuff is a wildcard. If they could figure out a per-hop queueing behavior that made things reasonable without complex queueing and scheduling, then maybe this is something that needs to be at this low, commodity layer. Assuming they can do it without IP encumberances which make commodity hardware impossible.
I think the goal could be a noble one. Not for the silly Internet of Things, or some niche. If they could make the lowest layers provide cheap, reasonable, fair packet forwarding performance, then this could enable an ISP to sell a much better connection for the general user, but still provide the leftovers for hogs.
This doesn't sound very Net Neutrality-ish.
Burn it with fire!
There's no time like the present. Well, the past used to be.
Modern Ethernet is really Ethernet in name only.
The multipoint coaxial segments are gone, replaced by point to point twisted pair. CSMA/CD is pretty much gone*. replaced by switching. The simple wire-level "manchester encoding" is pretty much gone repalced by a highly complex multilevel encodings with echo cancellation
All that is really left is the frame formats and the addressing scheme.
Just because a design descision made sense at a particular time and in a particular context does not mean it will make sense for all time and in all contexts.
* By pretty much gone, I mean that the hardware still supports it, but it's only used when connecting to legacy equipment.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I assume she is related to the three male Consortiums?
Blame that nonsense on the old science and technology propaganda from the 1950's/60's/70's and even into the 80's. They promised everything from flying cars to controlling absolutely everything in your home at the touch of a button. These ideas have ingrained themselves into the proceeding generations, and the result is utterly useless shit like Phillips Hue, Nest, and this nonsense.
@Mindless Drivel: 100% of Twitter posts ever Tweeted.
Ethernet is a technolgy with CSMA/CD Media Access. The new network is TDMA. It's funny. The telecom changed recently from TDMA to Ethernet in the backbones. Now the IoT changes from Ethernet to TDMA.
Blame that nonsense on the old science and technology propaganda from the 1950's/60's/70's and even into the 80's. They promised everything from flying cars to controlling absolutely everything in your home at the touch of a button. These ideas have ingrained themselves into the proceeding generations, and the result is utterly useless shit like Phillips Hue, Nest, and this nonsense.
I rather think it is/was just the search for the "next big thing". Smartwatches didn't work. The Internet of Things is an unfolding disaster.
We are in between the big things, and I'm curious what it will be.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
I'm seriously having ATM flashbacks from the 90s.
You younger folks might not remember this, but the segway hype was a weak echo compared to the ATM hype. ATM was going to transform the way we built our networks. Nothing was ever going to be the same after ATM. ATM was going to make all previous data and voice networking obsolete. People would kill to get ATM to the desktop.
If I'm reading this article right, someone went through the ATM specs and came up with a brand new set of names for the same old crap. It must be hell working in telecom. Their elegant circuit-switched networks are slowly being purged from the earth, replaced by vulgar packet-switched networks.
See that "Preview" button?