back to article Kill queues for fast data centres: MIT boffins

MIT researchers hope to speed up networking inside the data centre with concepts that will look familiar to old networking hacks: they propose a central arbiter for network traffic that picks out a predetermined path before a packet is transmitted. The boffins call the scheme Fastpass, and its other characteristic is that the …

Silver badge
Coat

Stupid on the most basic of levels

Given how cheap bandwidth is within a data center, who needs some centralized scheme to control traffic? I can't see how this is a better solution than eliminating bottlenecks where they occur based on capacity planning exercises.

Software-defined networking schemes like OpenFlow and Fastpass are solutions looking for problems.

1
4
Bronze badge

Re: Stupid on the most basic of levels

Bandwidth may be cheap and plentiful but low latency is more difficult to achieve (probably the primary consideration). What remains to be seen is how much latency the FCP processing requires - it has to get info from the application/endpoint and from across the network devices and other endpoints to make routing decisions. I'm not sure about their scalability claims but so I could never fathom that NSA was able to slurp so much data from across Internet.

4
0
Silver badge

Re: Stupid on the most basic of levels

not so sure about that. Bandwidth is one thing, QOS another. Is all traffic equal, even in a data center ? I suggest to the outside user, probably, but to applications using backend services, definitely not. One wants a critical financial lookup and update to happen ASAP, while a webpage refresh can drag on. I do accept that bandwidth is cheap inside data center, but this project is aimed at hyperscale centers, so it is outside my experience and I suspect, almost everyone elses.

Given that carrier grade TCP/IP can utilise the hardware around 90% before performance degrades, the claims seem suspect. However they were done in a Real World situation with measurable changes. Were those changes in queue lengths significant to outside user ? That I did not see answered. Regardless, still worth doing to test alternative solutions. Given that individual network nodes make decisions based on local information, unable to optimise the whole network state, a central controller might have a better performance if it is managing the total network state which this seems to be addressing. Need dedicated control channels and very fast silicon though.

2
0
Silver badge

Numbers please

This is going to be a hell of a calculation for (hate the term) ROI. Even the installation of sensors to determine whether this type of deterministic SDN is worthwhile adds to the calculation. Humpf. This is certainly the type problem I like to play with.

0
0
Silver badge

Circuit switched data

This all sounds suspiciously like circuit switched data to me. I thought Ethernet was to replace circuit switched data as it was simpler & cheaper?

I wonder how long it is before they decide to use 53 byte packets ;-)

1
0

Re: Circuit switched data

It's a hybrid of (virtual) circuit-switching and packet-switching, because the circuit can potentially be different for each packet on a connection. The point is centralizing the packet-switching decisions to take advantage of more information about the network state.

If the arbiter can keep up, there's a potential gain because that additional information can be used to reclaim some inefficiencies caused by distributed routing (and, as other people have noted, potentially to provide other features such as QoS). Whether it's useful in practice is another question; clearly the authors claim it is, in the particular environment they studied, but obviously generalizing from that result would be suspect.

2
0
Silver badge

There is a reason that competent USENET programmers ...

... are highly valued in data centers.

Kids these days think throwing the kitchen-sink at a problem is more important than actually understanding the guts of the issue. Sad, that.

3
3
Silver badge

Re: There is a reason that competent USENET programmers ...

"Those who fail to learn from the mistakes of their predecessors are destined to repeat them."

1
0
Anonymous Coward

Re: There is a reason that competent USENET programmers ...

Yes, can't move for USENET programmers in datacenters round here

0
0
Anonymous Coward

Re: There is a reason that competent USENET programmers ...

<insert obligatory comment from jake about having done this years ago, before computers were even invented. "Why is this even news?" follow-up optional>

1
1
Anonymous Coward

Already done in embedded-land, methinks

Here in embedded land there has been noise from various vendors punting deterministic Ethernet - specifically for low-latency applications.

Like this Fastpass it seems to be TDMA-by-another-name.

0
0
Paris Hilton

Also kind-of like Token Ring, no?

It does sound like CSD, TDMA, SDN and OpenFlow, and also a bit like Token Ring — an attempt to get the timing-coordination benefits of Token Ring under Ethernet, with a different logical and physical topology, and without the use of any token or talking stick to determine whose turn to talk it is.

Except that Fastpass addresses both the timing and the route to be taken by the packets, whereas each of these other technologies addresses one but not the other. (If I understand them correctly, TDMA and Token Ring each address timing and the assignment of turns, while OpenFlow and other forms of SDN address the route to be taken by packets. CSD just facilitates, and is sort-of an adjunct to, TDMA.) Oh, and that Fastpass may perhaps be more flexible and circumstances-adaptive than the others.

Is that about right?

1
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017