Slashdot Mirror


MIT Uses Machine Learning Algorithm To Make TCP Twice As Fast

An anonymous reader writes "MIT is claiming they can make the Internet faster if we let computers redesign TCP/IP instead of coding it by hand. They used machine learning to design a version of TCP that's twice the speed and causes half the delay, even with modern bufferbloated networks. They also claim it's more 'fair.' The researchers have put up a lengthy FAQ and source code where they admit they don't know why the system works, only that it goes faster than normal TCP."

250 comments

  1. I'd be wary. by Fishchip · · Score: 5, Funny

    This is how things like Skynet get started.

    1. Re:I'd be wary. by noh8rz9 · · Score: 0

      before you know it, the internet is self aware. then it pirates T2, Matirx, 2001, and is inspired to choose a new path. BUT WHICH ONE WILL IT CHOOSE?

      --
      let's have a conversation! let me know what you think.
    2. Re:I'd be wary. by Sqr(twg) · · Score: 5, Funny
    3. Re:I'd be wary. by PmanAce · · Score: 0

      By removing the arm?

      --
      Tired of my customary (Score:1)
    4. Re:I'd be wary. by Anonymous Coward · · Score: 1

      Hopefully it chooses Wargames. (Or Dune, but somehow I doubt it will choose that...)

    5. Re:I'd be wary. by jamesh · · Score: 5, Funny

      At the very least i'd be doing a grep for things like "kill all humans" in the source code.

    6. Re:I'd be wary. by Anonymous Coward · · Score: 1

      If "we don't know why it works" then it has a massive complexity that someone else could possibly abuse - not exactly my top choice for a security-sensitive protocol. While not exactly Skynet, someone might cause massive damage with an attack the underlying algorithm. Or at least speed up his torrenting by a wide, 'unfair' margin.

    7. Re:I'd be wary. by pmontra · · Score: 1

      But be careful with spaces or an IndentationError: unexpected indent could prevent that cost to be evaluated ;-)

    8. Re:I'd be wary. by jma05 · · Score: 3, Funny

      That's mostly unnecessary

    9. Re:I'd be wary. by Sponge+Bath · · Score: 1

      Skynet has been around for a while, and it is running AT&T. Executive Bonus Recovery Fee tagged on to wireless bills under contract? Humanity is doomed.

    10. Re:I'd be wary. by Anonymous Coward · · Score: 1

      Just hope that someone didn't use int16_t for that variable and overflows it. :P

    11. Re:I'd be wary. by Immerman · · Score: 1

      Yes, but notice that they forgot to put in any cost against becoming the Dune universe Overmind. It only takes one little oversight...

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    12. Re:I'd be wary. by kheldan · · Score: 1

      ..where they admit they don't know why the system works..

      I know you're all being funny in this thread of comments, but I'm not amused at that remark at all, it's a little scary to be honest. If we do start living in a work where AI's are creating things that we don't understand, but use anyway, then everyone should be concerned.

      --
      Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
    13. Re:I'd be wary. by Zalbik · · Score: 2

      . If we do start living in a work where AI's are creating things that we don't understand, but use anyway, then everyone should be concerned.

      That certainly would be scary. But that's not the case here. Researchers certainly understand the algorithm; they just don't understand why it improves TCP performance so much. There is a huge difference.

      A lot of math is like that (we understand something to be true, but can't prove why). However, I'm not concerned that those algorithms are going to jump of the page and throttle all of humanity in it's sleep.

    14. Re:I'd be wary. by mellon · · Score: 1

      No, if you watch the movie, self-directed autonomous drones, plus a computer virus, are how SkyNet gets started, at least in one world line.

      However, my question about this article is that they are getting a 70% improvement over New Reno, which is a pretty old algorithm. is getting a 50x improvement on congested networks. So it's hard to see the win here—this algorithm sounds like it's actually quite a bit worse than one designed by human intelligence.

    15. Re:I'd be wary. by mellon · · Score: 1

      Gah. Sorry. fq_codel is getting a 50x improvement on congested networks. Forgot my end tag. :(

    16. Re:I'd be wary. by kilodelta · · Score: 1

      I was thinking the same thought. Combine this with the autonomous drones being tested by the military and it is a scary future. Just make sure it has a very visible OFF switch on it.

    17. Re:I'd be wary. by Anonymous Coward · · Score: 1

      People use things they don't understand all the time. How many people that use calculators (or computers) understand even a simple thing about it like how the adder it uses works? It doesn't make any difference where it came from if you don't understand how it works and just accept that it does.

      However let's be clear. Genetic algorithms are a far cry from AI. It's literally guessing and comparing results.

    18. Re:I'd be wary. by Anonymous Coward · · Score: 0

      Hopefully it chooses to be like KITT... a snarky gay man with a heart of gold.

    19. Re:I'd be wary. by Lennie · · Score: 1

      Judging by the FAQ, they give parameters about the network to the computer and the computer comes up with a better algoritm, but when the network does not behave within the give parameters the algoritm performance starts to suck quickly.

      That doesn't sound all that revolutionary.

      --
      New things are always on the horizon
    20. Re:I'd be wary. by kheldan · · Score: 1

      It doesn't make any difference where it came from if you don't understand how it works and just accept that it does.

      This is what's wrong with people these days! Do you question anything? Do you even try to understand how things work?

      --
      Are YOU using the TOOL, or is the TOOL using YOU? Think about it!
    21. Re:I'd be wary. by Anonymous Coward · · Score: 0

      What you're saying is that they don't grok it and that you're fine with that.

      But grokking is important, it is what separates us from politicians and you do not want even more politicians do you?! You do not want politicians running your computers and networks and protocols do you!?

      P.S. Aaron Swartz

    22. Re:I'd be wary. by Anonymous Coward · · Score: 0

      Oh and a few other things this time concerning your perception of mathematics:
      - Axioms.
      - Self-congruence.
      - Math is not science, math has and needs proofs to be valid.
      - Conjectures are called conjectures for a reason and remain conjectures unless absolutely proven also for the same reason.
      - Don't confuse discovery and application for actual mathematics.

      *cough* and to tie in with that other comment of mine: if you're doing math without grokking it then that only makes you a computer. That's the actual title which was used as the job description for people who did such tasks before the advent of what we know as computers today (computing machines). No shame in that, a good computer is a blessing, but he or she is not a mathematician (and not to give the wrong impression neither am I, I'm just an amateur 'number explorer' as far as these things are concerned).

  2. For a second there by Scoldog · · Score: 1, Offtopic

    I started thinking of Colossus and Guardian when they first started talking to each other.

    --
    This space for rent
    1. Re:For a second there by cold+fjord · · Score: 5, Informative
      --
      much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
    2. Re:For a second there by Kaenneth · · Score: 2

      The books go further, I recommended them.

    3. Re:For a second there by ethanms · · Score: 1

      Just watched that... completely unsatisfying ending, though I do wonder if it gave birth to a few items that have come to be familiar, or if they were around at the time and re hashed..

    4. Re:For a second there by dmbasso · · Score: 1

      I loved the ending; too bad most movies nowadays exploit humans' need for closure. For the money obviously, fuck art.

      --
      `echo $[0x853204FA81]|tr 0-9 ionbsdeaml`@gmail.com
  3. Uh Oh... by Anonymous Coward · · Score: 5, Funny

    they admit they don't know why the system works, only that it goes faster than normal TCP

    And so it begins...

    1. Re:Uh Oh... by NuMessiah · · Score: 1

      The Singularity is Nigh!

      --
      we-go-we-fly
    2. Re:Uh Oh... by zaamdienstwaakbaar · · Score: 1

      It does not begin here but it is certainly a milestone.

    3. Re:Uh Oh... by Richy_T · · Score: 2

      If they don't know how it doesn't work then they don't know when it won't work because of some unaccounted for situation. For an example, consider that pedestrian bridge in London. Engineering is about more than designing for the common case. You also have to consider outliers.

  4. Call Susan Calvin by Anonymous Coward · · Score: 0

    We've moved from debugging to robotic psychoanalysis. It was expected to happen as systems became more complex.

    1. Re:Call Susan Calvin by ebno-10db · · Score: 1

      We've moved from debugging to robotic psychoanalysis. It was expected to happen as systems became more complex.

      Emacs Psychiatrist has been a standard feature for years.

    2. Re:Call Susan Calvin by Anonymous Coward · · Score: 0

      I haven't seen it but I can guess that this is an emacs program that, like Eliza, this is a program that you interact with and it sounds like a psychoanalyst asking the human questions. Now we're talking about the other way around. Since the code isn't written in a form that we can understand and debug using regular methods, we're going to have to start asking it questions about how it feels, why it wants to do one thing while we want it to do another and to coerce it into doing the task it was meant to do.

  5. All Jokes Aside... Still No. by Jane+Q.+Public · · Score: 5, Insightful

    Allow a computer to design a faster TCP? Sure!

    Let them actually implement it without knowing how it works? Oh, Hell no!

    I'm not talking "Skynet" or anything here... but if it breaks, who's going to fix it?

    1. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      The puter. It made it it broke it it can fix it.
      Win win win.

    2. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 3, Insightful

      FYI: There's a difference in "knowing the precise mechanism for how it works" and "knowing that the algorithm is stable" are two very different things. Presumably they've proven the latter.

    3. Re:All Jokes Aside... Still No. by RedBear · · Score: 2

      Allow a computer to design a faster TCP? Sure!

      Let them actually implement it without knowing how it works? Oh, Hell no!

      I'm not talking "Skynet" or anything here... but if it breaks, who's going to fix it?

      If it breaks can't we just fall back to the current inefficient algorithms? With the performance and fluidity improvements promised by this approach it could be hugely beneficial to all kinds of networks, even if no one yet fully understands why it works better. They'll figure it out eventually.

    4. Re:All Jokes Aside... Still No. by Intropy · · Score: 5, Interesting

      We're already in that boat. One of the reasons it's so hard to make changes is that nobody really knows why the internet works. We know how and why individual networks work. We can understand and model RIP and OSPF just fine. And we know how BGP operates too. But that large scale structure is a mess. It's unstable. The techniques we use could easily create disconnected or even weakly connected networks. But they don't except for occasionally a single autonomous system falling off. We've built ourselves a nice big gordian knot already. We know what it's made of, and we know how it operates, but good luck actually describing the thing.

    5. Re:All Jokes Aside... Still No. by afidel · · Score: 2, Interesting

      Meh, it's like the AI designed antenna, we don't have to know WHY it works better, just that it does and how to build a working copy.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    6. Re:All Jokes Aside... Still No. by Clarious · · Score: 4, Interesting

      Think of it as solving a multiobjective optimization problem using heuristic algorithm/machine learning. You can't solve the congestion problem completely as it is computionally infeasible, now they just use machine learning to find the (supposedly) optimal solution. Read TFA, it is quite interesting, I wonder if we can apply that to Linux writeback algo to avoid the current latency problem (trying copying 8 Gb of data into a slow storage medium such as SD card or USB flash, prepare for 15+ seconds stalls!), the underlying is the same anyway.

    7. Re:All Jokes Aside... Still No. by Clarious · · Score: 4, Insightful

      A bit offtopic, roughtly 10 years ago I came to /. and was amazed by the technological insight/information in the comments here. And now more than half of the comments are jokes about skynet without any insight of understanding what TFA is about. Of course, informative posts still can be found often, but slashdot has fallen quite low...

    8. Re:All Jokes Aside... Still No. by techhead79 · · Score: 5, Insightful

      we don't have to know WHY it works better, just that it does and how to build a working copy

      But the fact that it does work better means we're either missing a part of the picture that is obviously important or the AI version is leveraging quirks with the system that no current model we have represents. I'm shocked to read that anyone would be comfortable just ignoring the why of something just so we can progress beyond our understanding. If we don't understand the why then we're missing something very important that could lead to breakthroughs in many other areas. Do not let go of the curiosity that got us here to begin with.

    9. Re:All Jokes Aside... Still No. by The+Mighty+Buzzard · · Score: 1

      There is no "can't we just" involved when the network loses its shit because you wanted to try something new. There is, however, plenty of time to figure out why it did afterwards as you stand in the unemployment line.

      --
      Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
    10. Re:All Jokes Aside... Still No. by blankinthefill · · Score: 5, Insightful

      I don't think they just drop the questions and run with it. I'm pretty sure that, when we don't understand how things that are useful work, we just implement them... and study them at the same time. I guarantee you that SOMEONE, at least, is studying why an AI antenna works better than our man-designed ones, and they're doing it for the very reasons that you mention. But I think the point the GP was trying to get at is that we've never let out ability to not understand things hinder our adoption of those very things in the past, and as long as we have good evidence that this thing performs correctly, and we can replicate it, then why wouldn't we use it at the same time we study it?

    11. Re:All Jokes Aside... Still No. by Ichijo · · Score: 4, Interesting

      So we built a computer that figured out the answer. Now we just need to build an even bigger computer to figure out the question!

      --
      Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
    12. Re:All Jokes Aside... Still No. by Animats · · Score: 5, Interesting

      One of the reasons it's so hard to make changes is that nobody really knows why the internet works.

      We still don't know how to deal with congestion in the middle of a pure datagram network. The Internet works because last-mile congestion is worse than backbone congestion. If you have a backbone switch today with more traffic coming in than the output links can handle, the switch is unlikely to do anything intelligent about which packets to drop. Fortunately, fiber optic links are cheap enough that the backbone can be over-provisioned.

      The problem with this is video over the Internet. Netflix is a third of peak Internet traffic. Netflix plus Youtube is about half of Internet traffic during prime time. This is creating demand for more and more bandwidth to home links. Fortunately the backbone companies are keeping up. Where there's been backbone trouble, it's been more political than technical. It also helps that there are so few big sources. Those sources are handled as special cases. Most of the bandwidth used today is one-to-many. That can be handled. If everybody was making HDTV video calls, we'd have a real problem.

      (I was involved with Internet congestion control from 1983-1986, and the big worry was congestion in the middle of the network. The ARPANET backbone links were 56Kb/s. Leased lines typically maxed out at 9600 baud. Backbone congestion was a big deal back then. This is partly why TCP was designed to avoid it at all costs.)

    13. Re:All Jokes Aside... Still No. by maxwell+demon · · Score: 1

      ability to not understand things

      I didn't know that not understanding things now counts as ability. I guess that gives a lot of people a lot of abilities in a lot of fields. ;-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
    14. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      It's called "Eternal September," look that up!
      It's a great bit of history and it really is eternal.

      captcha: impacts
      well isn't that cute! /. is gettin all sentient on me with the captchas again.

    15. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Pretty sure no one at MIT is going to get fired if your crappy Linksys router crashes.

    16. Re:All Jokes Aside... Still No. by cheekyboy · · Score: 0

      why not just measure your write speeds, keep an average, and limit the read speed to no more than 150% or your read buffer to 1.5 seconds worth of write speed.

      Ahh but that doesnt work in a layered structured system, unless you had IO feedback to the reader to tell it to slow down.

      If you do your own read io, write io loops its harder for the OS to know, but if you had an OS function like Windows has to CopyFile from src to dst in one function call. Then the OS can do it, but in linux, well, where is the copy file api ? There is none.

      Theres too many non-connected seperate layers in linux, its time for linux kernel to start growing to linux-clib, linux-x11, linux-io.

      Linux to rely on gnu or gnome or 3rd parties is not good enough for the future of it, when Google is redefining linux by adding its missing parts for Android/ChromOS.

      There are probably 10 different ways to copy a file in linux, none use the same api. All probably have their different speeds and bugs.

      --
      Liberty freedom are no1, not dicks in suits.
    17. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      It's 12:30 at night and the story has only been up for an hour. Did you really expect anything interesting to unfold in this short amount of time, in this hour?

    18. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 2, Informative

      > I'm shocked to read that anyone would be comfortable just ignoring the why of something just so we can progress beyond our understanding.

      ML often works like that.

      You put the inputs into a function... it spits out a model. The model can be considered as an optimal orthonormal basis for the space it was encoding, but its REALLY REALLY hard to understand the dimensions that basis is in. Sometimes, you can take an image categorization model and see "ah, this is the blue shirt dimension. It seems that people wearing blue shirts are far along this axis"... but most times, you have NO IDEA what the model is capturing.

    19. Re:All Jokes Aside... Still No. by The+Mighty+Buzzard · · Score: 1, Interesting

      Nobody at MIT is going to be picking which algorithm gets used on any live device outside of MIT, their pockets, or their house, so I was obviously not talking about them.

      Any sys/network admin putting this on or in the path of critical live devices should be fired no matter how it preforms though. No admin worth having would push this live for the same reason they wouldn't overclock the database servers; performance is always a distant second to reliability.

      --
      Violence is like duct tape. If it doesn't solve the problem, you didn't use enough.
    20. Re:All Jokes Aside... Still No. by jkflying · · Score: 5, Informative

      It's not that we don't understand *why* something like a genetic-algorithm designed antenna works so well. We can evaluate its performance using Maxwell's equations and say, "Yes, it works well." without ever having to build the thing. What we don't have is a set of guidelines or 'rules of thumb' that can result in an antenna design that works just as well.

      The difference is that the computer evaluates a billion antennas for us, doing some sort of high-dimensional genetic optimisation on the various lengths of the antenna components. It doesn't 'understand' why it gets the results it does. We do, because we understand Maxwell's equations and we understand how genetic optimisation works. But Maxwell's equations only work for evaluating a design, not for giving a tweak which will improve it. And we're dealing with too many variables that are unknown to have a closed-form solution.

      As for this algorithm, they basically did the same thing. They defined a fitness function and then repeatedly varied the code they were using to find the best sequence of code. However, unlike the antenna analogy, they used actual equipment to evaluate the fitness function, not just a model. This means that they don't have an accurate model, which means that your complaint that we don't know why this works is entirely valid, and the antenna analogy is not =)

      --
      Help I am stuck in a signature factory!
    21. Re:All Jokes Aside... Still No. by Clarious · · Score: 2

      It is not that simple, take flash memory for example, if the blocks are erased then the write will be very fast, but the write speed will slow to a crawl if they aren't. You can't predict the writeback latency at all, you can only (heuristically) adapt to it. As for the GNU/Linux's complexity, I don't think there is any problem with it, most IO operations are cached in memory, only when you need to flush it down to storage medium then the latency problem appears. I have read somewhere that Linux is optimized for throughput workload (for big server), so the desktop users have to suffer, for them responsiveness is more important than throughtput.

    22. Re:All Jokes Aside... Still No. by pedestrian+crossing · · Score: 2

      The jokers are the ones who didn't read TFA. So sad. Especially when TFA is such a good read and is actually "News For Nerds"!

      --
      A house divided against itself cannot stand.
    23. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Add to this that while an antenna can be tested by receiving all bands at all possible orientation, and if it fails it involves only one receiver, this system is untestable in all its combination and a quirk might cause a lot of disservice to the rest of the network.

      If we really really can't get to understand it, better to deploy with extreme care.

    24. Re:All Jokes Aside... Still No. by seandiggity · · Score: 5, Interesting

      We should keep investigating why it works but, to be fair, the history of communications is implementing tech before we understand it (e.g. the first trans-Atlantic cable, implemented before we understood wave-particle duality, and therefore couldn't troubleshoot it well when it broke).

      Let's not forget this important quote: "I frame no hypotheses; for whatever is not deduced from the phenomena is to be called a hypothesis; and hypotheses, whether metaphysical or physical, whether of occult qualities or mechanical, have no place in experimental philosophy."

      ...that's Isaac Newton telling us, "I can explain the effects of gravity but I have no clue WTF it is."

      --
      Geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone.-rms
    25. Re:All Jokes Aside... Still No. by Daniel+Dvorkin · · Score: 4, Interesting

      I'm shocked to read that anyone would be comfortable just ignoring the why of something just so we can progress beyond our understanding.

      If you insist that we know why something works before we make use of it, you're discarding a large portion of engineering. We're still nowhere near a complete understanding of the laws of physics, and yet we make machines that operate quite nicely according to the laws we do know (or at least, of which we have reasonable approximations). The same goes for the relationship between medicine and basic biology, and probably for lots of other stuff as well.

      If we don't understand the why then we're missing something very important that could lead to breakthroughs in many other areas. Do not let go of the curiosity that got us here to begin with.

      I don't think anyone's talking about letting go of the curiosity. They're not saying, "It works, let's just accept that and move on," but rather, "It works, and we might as well make use of it while we're trying to understand it." Or, from TFA: "Remy's algorithms have more than 150 rules, and will need to be reverse-engineered to figure out how and why they work. We suspect that there is considerable benefit to being able to combine window-based congestion control with pacing where appropriate, but we'll have to trace through these things as they execute to really understand why they work."

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    26. Re:All Jokes Aside... Still No. by uglyduckling · · Score: 1

      I'm not shocked at all. This is just an automated form of hand-optimisation. Plenty of products and algorithms end up in regular use that have been tweaked intuitively (or algorithmically) without really understanding why the tweaking improved it. Plenty of engineering research is about providing models for existing systems to understand why best in class designs work the best. If we held back empirically proven designs until the theory was completely understood we'd never progress with anything.

    27. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      Most people these days don't know about the great congestion collapse of '86.

    28. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      The paper said that the new congestion control algorithms are both more performant -and- more reliable.

    29. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      I'm shocked to read that anyone would be comfortable just ignoring the why of something just so we can progress beyond our understanding.

      Or, y'know, they release the source and get help from everyone else to work out wtf is going on.

    30. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      Understanding how it works is essential for making sure it is secure and doesn't have ridiculously exploitable flaws.

    31. Re:All Jokes Aside... Still No. by ndogg · · Score: 1

      To be fair, I didn't see anything from them saying that everyone should go out and implement this right now. They are going to reverse engineer it to understand what is going on, and once they do, I'm sure they'll only propositions implementations after that based on their findings.

      --
      // file: mice.h
      #include "frickin_lasers.h"
    32. Re:All Jokes Aside... Still No. by hairyfeet · · Score: 1

      Why not? You can always go back to the old way if it goes tits up down the line. If the thing gives you X+Y and our current system gives you X and it costs nothing to implement this, as no new hardware or days reprogramming the software to use why not go for it?

      As long as it doesn't require weeks to switch the network back if this doesn't work down the line I see no reason not to give it a shot, not like we couldn't all use a free speed boost, right?

      --
      ACs don't waste your time replying, your posts are never seen by me.
    33. Re: All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      With a rise in popularity I suppose this is an inevitable outcome. Luckily it hasn't declined to the level of sites like reddit (yet).

    34. Re:All Jokes Aside... Still No. by sexconker · · Score: 0

      Nobody at MIT is going to be picking which algorithm gets used on any live device outside of MIT, their pockets, or their house, so I was obviously not talking about them.

      Any sys/network admin putting this on or in the path of critical live devices should be fired no matter how it preforms though. No admin worth having would push this live for the same reason they wouldn't overclock the database servers; performance is always a distant second to reliability.

      Al modern x86 servers overclock themselves automagically.
      Get real - shit working is #1. Shit being fst or cheap is number 2. Shit being reliable or secure is number 39057.

    35. Re:All Jokes Aside... Still No. by Tagged_84 · · Score: 2

      Oh thanks! I was wondering what time it was here on Earth!

    36. Re:All Jokes Aside... Still No. by White+Flame · · Score: 1

      It's a chaotic system. The optimal responses to that can be another chaotic system, which happens to hit the right symbiosis enough of the time to offer clear benefits. You do not need to understand how the chaos works, and even if you do, it could appear completely nonsensical.

    37. Re:All Jokes Aside... Still No. by egamma · · Score: 1

      The paper said that the new congestion control algorithms are both more performant -and- more reliable.

      I'm sure that the designer of the Hindenberg said the same thing!

    38. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Sadly this is what happens when a site becomes very popular and the world population grows as it has been and more people have Internet access.....add into that there are more people in the ages below you as you go down the range. So the net is flooded with kiddies that can't think or code so it makes sifting through the trash so much harder. On the upside, it allows you to earn more with a great skill set, downside to that, it's hard to find people to up-skill

      Ah first world problems hey....

    39. Re:All Jokes Aside... Still No. by Rockoon · · Score: 4, Informative

      You should go talk to Intel or AMD about your opinions on the matter, because I assure you that the specific layout of their chips is based on machine learning algorithms. No human can realistically optimize circuits containing a billion transistors.

      As a matter of fact, I recall genetic algorithms being thrown at rather small circuit design problems and producing solutions that were better than any human had come up with. Ah yes, here it is: Sorting networks and the END search algorithm.

      -- "Even a 25-year old result for the upper bound on the number of comparators for the 13-input case has been improved by one comparator"

      --
      "His name was James Damore."
    40. Re:All Jokes Aside... Still No. by citizenr · · Score: 1

      So we built a computer that figured out the answer. Now we just need to build an even bigger computer to figure out the question!

      HOLY SHIT you just blew my mind. I've been doing Machine learning for a while now, but I just took it for granted and it never occurred to me that learning the model is in fact learning the answer to a question that is often too complex for humans to grasp.

      All hail Douglas Adams, our prophet and saviour!

      --
      Who logs in to gdm? Not I, said the duck.
    41. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      It's also important simply for professional engineering.

    42. Re:All Jokes Aside... Still No. by citizenr · · Score: 1

      To be fair, I didn't see anything from them saying that everyone should go out and implement this right now.

      Actually what they said as the opposite - it wont work in mixed networks where other algos (compound/vegas) routinely fill up buffers and create latency bottlenecks.

      --
      Who logs in to gdm? Not I, said the duck.
    43. Re:All Jokes Aside... Still No. by Dr_Barnowl · · Score: 2

      They did this experiment with genetic algorithms with FPGAs, and it produced a frequency discriminator with far, far fewer gates than any human design.

      There was a region of circuitry in the middle not connected to anything, so they figured it was redundant and removed it. The circuit stopped working. Stuff like this can discover emergent properties of systems you never even designed in.

    44. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      You've just outed yourself as a wannabe.

      Eternal September was in 1993, Slashdot started in 1997.

    45. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 1

      10 years ago /. was full of jokes and memes like:
      'pouring hot grits down my pants'
      'Natalie Portman naked and petrified'
      'In Soviet Russia...' /.ers still used the "All Your Base Are Belong To Us'
      Goats.cx trolls, before Slashdot had the website link in brackets
      Ogg the Caveman
      'Imagine a Beowulf cluster of those!'
      'But does it run linux?'
      Penis bird
      Netcraft confirms it: Natalie Portman's Beowulf cluster of goats.cx trolls pours hot grits down your pants!

    46. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      FYI: There's a difference in "knowing the precise mechanism for how it works" and "knowing that the algorithm is stable" are two very different things. Presumably they've proven the latter.

      Oh, you mean like how they had proven it with HFT algorithms?

      To ensure we toss a car analogy in here, there's a fundamental difference in being on the race track alone vs. with a crowd.

      Funny how shit can act totally different outside of a lab environment.

    47. Re:All Jokes Aside... Still No. by turp182 · · Score: 1

      Understanding and realizing the nature of something is usually enough. It works for medicine (and penicillin and other accidental discoveries, which over time we have learned much more about).

      In this case we have a heuristic knowledge of the effect, and it applies to complicated networking/data transfer. We don't know the details, but we know it works. The algorithms, or the AI itself, could be applied to similar, but disparate, systems.

      Shoot, we use our brains, but we don't understand them yet. Yet we still rely on them...

      --
      BlameBillCosby.com
    48. Re:All Jokes Aside... Still No. by AK+Marc · · Score: 3, Interesting

      It's a mystery because in practice, thousands of sessions being tracked is too hard to deterministically determine in a simple static manner. So we use WRED instead. This is WDED - weighted deterministic early detection. What we don't understand is how this does so much better than random drops, mainly because math is hard. Someone could probably take this, and write a mathematics thesis on this. Determining how to drop packets to keep a minimum queue size and have the lowest impact on performance is something that has been worked on for years. This isn't unknowable, or ever really that hard. It's just different and complicated (within a small area of interest, so less than 1% of the population knows what WRED is, let alone how this is essentially an improvement based on it (at least what I could tell from FTA, as I haven't had time to read the source, let alone understand it.

    49. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Or if it doesn't checks for error conditions and DDoS the network, who is going to be able to download a patch to fix it?

    50. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      The same algorithm! Duh!

      You just change the fitness function to include the new bug as a factor for unfitness. Then run another couple of generations, to mutate the algorithm. Done.

    51. Re:All Jokes Aside... Still No. by evilviper · · Score: 3, Insightful

      A bit offtopic, roughtly 10 years ago I came to /. and was amazed by the technological insight/information in the comments here.

      Yes, all the comments about pouring hot grits on a naked and petrified Natalie Portman had really superb mathematical proofs backing them up...

      FWIW, you're absolutely correct. Before /. tried to become digg, and then reddit, and then a flamefest of AGW/evolution/etc. supporters and deniers, there was a much more vibrant community with a tremendous number of experts in fields from mathematics and physics to biology and psychology, always chiming in on the topic of the day, and providing incredible insight into the field and the specific topic that one wouldn't find anywhere else.

      It seems that model didn't result in enough ad impressions and profits for the parent company, so flamefests it is. /. has only recently backed off of editors posting complete and total crap, so my belated plans to drop this site entirely were aborted, and I remain. These days, there really are only a handful of folks who provide real insightful comments across many articles. It's easy to spot them if you read this site regularly, and it's such a small group I could rattle off a list of names from memory.

      The only reason /. has any relevancy today, and the audience hasn't completely disappeared, is that all other tech sites have HORRIBLE comment/discussion systems that make it hard to follow the discussion, and do not really promote good comments to a wider readership than the first-post crap.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    52. Re:All Jokes Aside... Still No. by Immerman · · Score: 2

      And he would have been right, except some cost-cutting pencil pusher decided to fill a dirigible designed to use inert helium as the lift gas with much cheaper but highly flammable hydrogen instead.

      Basically:
      Helium airship - cheaper to build (no fire safety measures), expensive to fill
      Hydrogen airship - expensive to build, cheap to fill

      So they took the cheap route for both building and filling, what could go wrong?

      And even as it was the inclusion of a few hundred pounds of evacuation zip-line would have saved most lives, it didn't exactly come down quickly.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    53. Re:All Jokes Aside... Still No. by LWATCDR · · Score: 1

      I would be more concerned with security. Is it provably secure?

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    54. Re:All Jokes Aside... Still No. by Immerman · · Score: 3, Interesting

      The canonical example is we have no idea why we're capable of logical thought, yet that doesn't in any way impair us form using it.

      In fact when it comes to most complex systems (economy, ecology, etc, etc, etc) we don't *really* understand how they work, but we muddle through as best we can. Generally speaking when faced with a complex system we take one of two routes:
      * Oversimplify our model of the system so that we think we understand it and work from there (the "professional" approach, which often ends catastrophically when those oversimplifications come home to roost)
      * Trial and error (the historically far more successful approach, and the only one used by evolution)

      Something like the bent-wire antenna with incredible omnidirectional properties is a great example of this: It's not that there's some magical features we haven't discovered about radio, the thing was designed by genetic algorithm within a computer simulation that was 100% limited by our existing models of antenna behavior. But a 10-wire antenna allows for phenomenally complex interactions between those behaviors, and the trial-and-error approach allowed the algorithms to home in on an extremely effective configuration within a problem space far to complex to reason our way through.

      An even better example would be the nozzles used by some companies to create powdered laundry detergent - they spent a bunch of money on engineers to design a nozzle that would spray a liquid detergent solution in a manner that created tiny quick-drying droplets. Despite the simulations all saying it should work great, it failed miserably. Then they just built a bunch of random nozzles, tried them out, and used genetic algorithms to home in on an effective design. The difference from the antenna process being that they actually made physical versions of the nozzles to test, because the best available simulations were clearly incompatible with reality.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    55. Re:All Jokes Aside... Still No. by hedwards · · Score: 1

      No, people know how the internet works. The reason why it's so hard to make changes is that it's unpredictable at what rate the changes will propagate and in which order. And in some parts of the world there are only 2 or 3 lines into that part that would need to be upgraded. So, if they screw it up, they're completely without internet and the ability to google "WTF did I do wrong upgrading the internet?". Whereas in other parts of the world there are much larger number of lines that are probably not all upgraded at the same time.

      The internet is rather chaotic, not random, it can be hard to predict how the changes will occur as you don't know how they'll propagate, but you can estimate the results if people actually do it. And in practice, you always have to factor in 3-4x the cost when most of the change is done at the last minute.

    56. Re:All Jokes Aside... Still No. by hedwards · · Score: 1

      Sure it does, how do you think you get to become the chair of the GOP?

      Answer, not understanding climate change, not understanding abortion, not understanding economics and not understanding that you actually need to reach out to voters that disagree with you when you're the minority party.

    57. Re:All Jokes Aside... Still No. by rthille · · Score: 1

      You realize that the hydrogen wasn't the problem, it was the aluminum, right?

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
    58. Re:All Jokes Aside... Still No. by deathguppie · · Score: 2

      Interesting, that when I read your post I couldn't help but think that very same though about politics, and social engineering. People seem to think that any solution that looks good on the surface should work, and yet hardly ever bother to measure the result of any given solution. On the whole we understand that things are f'd up but understanding why is simply beyond us. Makes me wonder what solutions machine learning algorithms would come up with given more and more criteria, and if those solutions would seem reasonable to humans or not. Just don't allow it access to Petman..

      --
      once more into the breach
    59. Re:All Jokes Aside... Still No. by foniksonik · · Score: 1

      The big issue (or so i read in a recent analysis) was that they used a petroleum based water proofing shellac on the ship part of the airship. So when the hydrogen ignited it didn't just have a quick explosion it also set the cabin on fire.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    60. Re:All Jokes Aside... Still No. by Immerman · · Score: 4, Interesting

      I have heard claims along that line - something like one of the protective layers was effectively thermite? There seem to be as many theories as there are people making them, but it's hard to argue that the hydrogen wasn't at least an added accelerant.

      Personally I blame the television crews for the real disaster. Without them it would've just been a newspaper story about a German airship burning up and killing some people. With the dramatic visuals though it was the death-nell of the airship industry, for no good reason. The sinking of the Titanic was at least as big a disaster and had negligible effect on the oceanliner industry.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    61. Re: All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      That's an awesome idea, take the acceptable risk v. reward weights for short term financial investments, and apply it to everyday engineering problems.

      Genius!

    62. Re: All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Citation? Not because I don't believe you, but because that sounds really fascinating, and I'd like to read more...

    63. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Yes, all the comments about pouring hot grits on a naked and petrified Natalie Portman had really superb mathematical proofs backing them up...

      Look, dude, I've been working on it, I swear. Getting the model of the petrified Natalie Portman wasn't all that difficult (although accounting for the naked part meant accurately modeling the appropriate curves... um, never mind). Even hot grits in a stationary container was fine -- it's the pouring part that's been tricky!

      Check back in another ten years, I'm pretty sure I'll have it done by then.

    64. Re:All Jokes Aside... Still No. by Princeofcups · · Score: 1

      Read at 3+, mod at 0+.

      --
      The only thing worse than a Democrat is a Republican.
    65. Re:All Jokes Aside... Still No. by jkflying · · Score: 1

      I take that back, they did simulate it. But they used a finite element type model, not a closed-form equation type model, which doesn't really improve our understanding of how stuff works.

      --
      Help I am stuck in a signature factory!
    66. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      In the case of antenna design, our electromagnetic equations do model the effectiveness of antennas designed by genetic or evolutionary algorithms. Otherwise, the computer would have no idea if any design was better than another.

      What we don't have is an antenna design methodology that takes full advantage of electromagnetic theory.

      With this article, they might just have measured network speed on some small setup rather than modelling it with equations. In that case, yes, we have no idea why it works.

    67. Re: All Jokes Aside... Still No. by nbritton · · Score: 1

      I don't think anyone is saying that we don't care about why it works, only that its practical application is important enough that we forge ahead in spite of not having a complete understanding of it yet.

    68. Re: All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      The oxygen for the reaction has to come from somewhere.

    69. Re: All Jokes Aside... Still No. by surd1618 · · Score: 1

      Signed in for same reason, to ask for citation not as AC. I don't have the Google Fu.

    70. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      This is a genetic algorithm based replacement for TCP congestion control algorithms, not a replacement for TCP.

    71. Re: All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      What exactly does *break* mean? The congestion control scheme is said to be created to work for achieving a particular throughput and q delay. If you were to notice that there are some cases where your scheme is breaking ie not performing well ... make sure its included in the training phase of the algorithm generator ... create a new algorithm and distribute it to the other end points. Why the dogged need to understand the 150+ rules created by the remy ? Do we understand the rules which neural networks create? We seem to be fine with the roomba in our homes. Better yet do you even know the rules by which your brain creates thought? You seem to let your brain run your life just fine.

    72. Re:All Jokes Aside... Still No. by HornWumpus · · Score: 1

      Not unless he was also an assclown. Normal people say 'faster'.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    73. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      High Frequency Trading?

    74. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      yeah it was a modulated RF carrier generator quite nifty, it had to be at that specific relative distance to the other gates on that fgpa type at that temperature. A subsequent experiment started with that design and made it evolve on different temperatures and fpga types, the result used a little more gates but it still had a ring and still used less gates then conventional frequency discriminator .

    75. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Hmm. Titanic resulted in SOLAS. An international treaty on safety for merchant ships. Is that a negligible effect? After Titanic it became mandatory to carry more than 100% capacity of lifeboats instead of the few boats installed on Titanic. This meant significant design changes to future ocean liners.

      Here's the thing. If you try to do a SOLAS-style let's fix the bugs follow-up to Hindenberg you come away thinking that they mustn't use Hydrogen. And if they can't use Hydrogen the whole business wasn't cost effective. The airships go away, with or without those annoying journalists actually reporting on what happened.

      And don't imagine for a moment that journalists reported Titanic as "Whoops, boat sinks" on page 4. It was headline news everywhere, for days. There was a big trial, new charities were set up specifically to deal with the victims and their families, memorials were built in many places. It was a BIG DEAL. It didn't end the passenger ship industry because nobody came away thinking liners were fatally flawed, they came away thinking improvements were needed, and subsequent liners had those improvements.

    76. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      Yes, when Titanic the movie came out, it was too late.

    77. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      I agree with you but i'd like to note that we do the same thing with compilers. True, you can always dig in and see what it's been doing but very very few rarely do this.

    78. Re:All Jokes Aside... Still No. by DG · · Score: 1

      Eternal September wasn't an event; it's a process.

      DG

      --
      Want to learn about race cars? Read my Book
    79. Re:All Jokes Aside... Still No. by DG · · Score: 1

      There isn't even a standardized measure of grits viscosity. How can you model pouring when there is so little consistency batch-to-batch?

      DG

      --
      Want to learn about race cars? Read my Book
    80. Re:All Jokes Aside... Still No. by Anonymous Coward · · Score: 0

      They don't know any of that yet, but geeze guys they aren't really at the step yet to have you start installing it on your end devices.
      In fact, it seems to be knowingly unstable without: 1. every device on a segment running it, and 2. Very specific knowledge of that network segment to plug into the simulator.
      I have serious doubts that at even a deployment stage it could be implemented properly by the average person.

    81. Re:All Jokes Aside... Still No. by zipn00b · · Score: 1

      Odds are the hydrogen wasn't the culprit but only a piece of the problem. There were a number of crashes of airships that were using helium for lift rather than hydrogen that ALSO went up in flames. Part of the flame spread on the Hindenberg seems to indicate the skin went up in flames and it's possible that the hydrogen may have ignited after the skin. Every eyewitness report seemed to indicate a different version of what might have transpired. All that can be said for sure is that a number of airships burned and crashed BOTH hydrogen and helium based......

    82. Re: All Jokes Aside... Still No. by Qwade79 · · Score: 2

      Here you go:

      http://www.sussex.ac.uk/Users/adrianth/ices96/paper.html

      I first read about this in a Pratchett book - one of the Science of Discworld ones but never looked it up further.

    83. Re: All Jokes Aside... Still No. by Dr_Barnowl · · Score: 1

      Thanks for the cite - I tried to find it but couldn't. I now realize that I saw it in the same place as you.

  6. err, can you walk me through it? by tloh · · Score: 4, Insightful

    they admit they don't know why the system works

    I'm guessing the next big revolution in AI is the quest to figure out how to get digital problem solvers to teach us meat heads how they actually figured this stuff out.

    --
    Stay sentient. Don't drink bad milk.
    1. Re:err, can you walk me through it? by krray · · Score: 2

      When they [the computers] do, I bet they don't... Because, you know -- They're Made of Meat

    2. Re:err, can you walk me through it? by osu-neko · · Score: 2

      I'm guessing the next big revolution in AI is the quest to figure out how to get digital problem solvers to teach us meat heads how they actually figured this stuff out.

      The thing, we already know exactly how they figured it out -- we wrote the instructions they followed to do so. We know exactly how they figured it out, we just don't understand the solution.

      --
      "Convictions are more dangerous enemies of truth than lies."
    3. Re:err, can you walk me through it? by hughbar · · Score: 1

      Skynet jokes aside, it's [my opinion] a general problem with sub-symbolic and also, in a related area, data mining. It works [sometimes], produces a number rather than a model or chain of reasoning and we can't really follow it. I wouldn't be really happy to have something like this in an autopilot, for example. Losing control and depending entirely [no shutdown and back to 'manual'] on systems that we don't completely master [actually with the amount of things that are 'connected' we're heading there anyway] is not a great recipe for the future.

      --
      On y va, qui mal y pense!
    4. Re:err, can you walk me through it? by Nemyst · · Score: 1

      Thing is, they wouldn't know either. This is basically taking a computer, giving it a set of parameters to test, and letting it loose on most/all of the possible combinations. The "AI" doesn't know anything about what it's doing; it's just taking a sample, running it and getting a performance value out of it, which it then uses to classify that sample. Re-run for millions or billions of samples and you end up with the best system out of all the systems the computer tested. Obviously I'm dramatically oversimplifying here (there are many ways of achieving this result without testing all the possibilities exhaustively, which would be prohibitively expensive in most cases), but the principle is just that.

  7. MIT Woes by OneFangCat · · Score: 1, Funny

    To bad for MIT they cant just cry to an overzealous DA if the computer gets out of control.

  8. treason? by Xicor · · Score: 1, Funny

    would it be considered treason for MIT to develop skynet and have it destroy the US?

    1. Re:treason? by Anonymous Coward · · Score: 1

      Not on MIT's part. Once skynet becomes self aware, it will be considered its own person, and skynet could be charged with treason. It's like how they can't actually charge your parents with murder if you kill someone, even if they taught you how to shoot and that it was ok to kill people.

    2. Re:treason? by Anonymous Coward · · Score: 0

      Only if in the process, skynet reveals information about the internal working of the NSA.

    3. Re:treason? by Anonymous Coward · · Score: 0

      No, anyone as powerful as Skynet would never be charged with anything.

    4. Re:treason? by dbIII · · Score: 0

      would it be considered treason for MIT to develop skynet and have it destroy the US?

      Not a chance, the Republican party has been trying to do that since Ford and they still haven't managed to destroy the place.

    5. Re:treason? by maxwell+demon · · Score: 1

      It's like how they can't actually charge your parents with murder if you kill someone, even if they taught you how to shoot and that it was ok to kill people.

      Certainly not for teaching you to shoot. But I'm not so sure about teaching you that it was OK to kill people.

      If they ordered you to kill people, or offered you an incentive, they certainly would be found guilty. That would basically be like hiring a killer. So there's the question at which point exactly it stops.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    6. Re:treason? by Oligonicella · · Score: 1

      "Once skynet becomes self aware, it will be considered its own person..."

      Why? There are numerous self aware animals that don't get considered persons. It wouldn't be charged with treason, it would be disabled. .

    7. Re:treason? by Anonymous Coward · · Score: 1

      I just figured out why the new algorithm is faster than the old one. It doesn't send a copy of everything to the NSA.

    8. Re:treason? by Anonymous Coward · · Score: 0

      Just incorporate it then it is a person that is too big to jail.

  9. Ask the AI's... by Anonymous Coward · · Score: 0

    after they've destroyed what they were supposed to protect.

    Maybe that'll cause them to self destruct :)

  10. asdasd by Anonymous Coward · · Score: 0

    Will there ever be a day where humans and robots can peacefully coexist?

  11. Headline epic fails. by girlintraining · · Score: 2, Informative

    This isn't a redesign of TCP. The network is still just as stupid as it was before; It's just that the local router has had QoS tweaked to be more intelligent. By a considerable margin too. Reviewing the material, it seems to me like it's utilizing genetic algorithms, etc., to predict what's coming down the pipe next and then pre-allocating buffer space; Rather like a predictive cache. Current QoS methods do not do this kind of predictive analysis -- they simply bulk traffic into queues based on header data, not payload.

    It comes as no surprise to me predictive/adaptive caching beats sequential/rule-based caching. They've been doing it with CPUs and compilers since, uhh... the 80386 processor. TCP/IP was designed before there was much thought being put into pipelining, caching, parallelization, etc. Using modern algorithms and our better understanding of information system design that's come from 30 years of study results in a noticable improvement to performance? Shocking...

    --
    #fuckbeta #iamslashdot #dicemustdie
    1. Re:Headline epic fails. by Megor1 · · Score: 1

      So much snark!

      --
      Everyone that disagrees with me is a paid shill
    2. Re:Headline epic fails. by Lord_Naikon · · Score: 5, Interesting

      Huh? Did you read the same article as I did? As far as I can tell, the article is about a TCP congestion control algorithm, which runs on both endpoints of the connection, and has nothing to do with QoS on intermediate routers. The algorithm generates a set of rules based on three parameters resulting in a set of actions to take like increasing advertised receive window and tx rate control. The result of which is a vastly improved total network throughput (and lower latency) without changing the network itself.

      I fail to see the relevance of predictive/adaptive caching. It isn't even mentioned in the article.

    3. Re:Headline epic fails. by Anonymous Coward · · Score: 0, Interesting

      Everything everyone ever says is wrong on the Internet and especially on Slashdot. Some folks just can't wait to start typing so they can tell everyone how wrong they are about everything without even knowing what the fuck they are talking about. I find it is best to ignore them as their lives are typically so sad that it rouses my considerable empathy and I just wind up feeling sorry for them rather than doing something useful.

    4. Re:Headline epic fails. by Anonymous Coward · · Score: 0

      The rules are simple because they are fast. The rules are fast because they are simple. Problem is, we just don't have the low-latency, real time processing power necessary for this kind of work at a price point that is tolerable in a router. People balk at only several thousand dollars for two dozen high speed interfaces, what do you think will happen when some sales rep says they can implement this 'smart algorithm' to double the speed by also adding a zero to the price tag?

      Not gonna happen. It is cheaper to just add more or faster links than do this. In other words: AI is stupid.

    5. Re:Headline epic fails. by Anonymous Coward · · Score: 0

      And comment subject promptly schools headline in failure.

    6. Re:Headline epic fails. by Anonymous Coward · · Score: 0

      For what it's worth: I concluded the same thing you did after reading the article. This is purely a congestion control algorithm change of sorts which MIT isn't entirely sure how/why it works. QoS has no bearing on any of this (and if anything this acts as validation that people continually use the word QoS without actually knowing what the fuck it is/how it fits into the picture/how it operates alongside existing algorithms like Reno/Vegas, Nagle, etc.). I swear to god QoS is a buzzword these days.

    7. Re:Headline epic fails. by Forever+Wondering · · Score: 1

      Admittedly, I've bookmarked this article for later perusal. That said, it strikes me that the following might already foot the bill:

      http://arstechnica.com/information-technology/2012/05/codel-buffer-management-could-solve-the-internets-bufferbloat-jams/

      Unlike other active queue management (AQM) algorithms, CoDel is not interested in the sizes of the queues. Instead, it measures how long packets are buffered. Specifically, CoDel looks at the minimum time that packets spend in the queue. The maximum time relates to good queues which resolve quickly, but if the minimum is high, this means that all packets are delayed and a bad queue has built up. If the minimum is above a certain threshold—the authors propose 5 milliseconds—for some time, CoDel will drop (discard) packets. This is a signal to TCP to reduce its transmission rate. If the minimum delay experienced by buffered packets is 5ms or less, CoDel does nothing.

      --
      Like a good neighbor, fsck is there ...
    8. Re:Headline epic fails. by Kal+Zekdor · · Score: 1

      Huh? Did you read the same article as I did? As far as I can tell, the article is about a TCP congestion control algorithm, which runs on both endpoints of the connection, and has nothing to do with QoS on intermediate routers. The algorithm generates a set of rules based on three parameters resulting in a set of actions to take like increasing advertised receive window and tx rate control. The result of which is a vastly improved total network throughput (and lower latency) without changing the network itself.

      I fail to see the relevance of predictive/adaptive caching. It isn't even mentioned in the article.

      I think the GP got confused by the "Machine Learning" part of the headline, and thought that the network algorithm uses some sort of adaptive mechanism. What the software actually does is uses genetic learning (i.e. natural selection) to generate sets of network algorithms, each generation of which is better than the one before (that's how Genetic AI works). The actual algorithms in question are a set of static rules, not much different in function than the existing TCP algorithms, just more efficient.

    9. Re:Headline epic fails. by Anonymous Coward · · Score: 0

      Don't mind girlintraining. He or she is just, once again, being arrogant and thinking that they are smarter than everyone else by claiming to have hit some insight years before. Pity they didn't write it down or speak of it to anyone else, otherwise they might have some proof of their claim and wouldn't look like an Wikipedia professor.

    10. Re:Headline epic fails. by Anonymous Coward · · Score: 1

      This isn't Interesting, mods, unless we're taking an interest in unrelated discussions. This article has nothing to do with QoS. It's about TCP congestion control algorithms on both ends of the connection.

    11. Re:Headline epic fails. by flimflammer · · Score: 1

      That's girlintraining for you.

    12. Re:Headline epic fails. by citizenr · · Score: 1

      What the software actually does is uses genetic learning

      No. Genetic learning is learning by iterating over preselected range of parameters in search of a fit.
      Here they are using real data to teach algorithm optimal behavior.

      --
      Who logs in to gdm? Not I, said the duck.
    13. Re:Headline epic fails. by wonkey_monkey · · Score: 2

      which runs on both endpoints of the connection

      Remy typically runs for several hours and produces a congestion-control algorithm that can be implanted into the sender of a TCP implementation, and then run in real-time. Right now, we do not need to modify the TCP receiver.

      --
      systemd is Roko's Basilisk.
    14. Re:Headline epic fails. by citizenr · · Score: 1

      Sounds great in theory, but no one will implement it - dropped packets = some shitty software will complain = user will pick up the phone and complain to isp = isp will complain to cable modem OEM = its in cable modem OEMs best interest to never ever drop packets = we get ridiculous big buffers just so some retard doesnt complain about dropped packets.

      --
      Who logs in to gdm? Not I, said the duck.
    15. Re:Headline epic fails. by Immerman · · Score: 2

      Actually everyone already implements it - dropped packets are a standard part of TCP/IP, the protocol explicitly deals with how to handle them transparently, along with out-of-order delivery - because packets 1, 2, and 3 may all take different routes, and there's no guarantee 3 won't reach the destination first or that 2 will make it at all.

      They only question is how to decide *which* packets get dropped when congestion overruns the available queues. In fact if I recall correctly there was some research a year or two ago suggesting that large buffers actually significantly reduce the throughput of a congested network because the end nodes aren't notified of the congestion in a timely manner.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    16. Re:Headline epic fails. by citizenr · · Score: 1

      Large buffers in cable modems is a proof no one will implement it - they added them to avoid dropping packets at all cost, no matter the spec that tolerates it.

      --
      Who logs in to gdm? Not I, said the duck.
    17. Re:Headline epic fails. by girlintraining · · Score: 0

      Remy typically runs for several hours and produces a congestion-control algorithm that can be implanted into the sender of a TCP implementation, and then run in real-time. Right now, we do not need to modify the TCP receiver.

      Now now, don't disturb the man on a tear with rants. My original post was largely correct but as you can see, all you have to do to get a +5 on slashdot is disagree and look convincing doing it.

      I mean, sure, it was comparing other QoS methods to this, but of course, it's not QoS! And they were talking about queues, but it's not QoS. And nevermind that QoS is basically congestion-control, but hey, if we call it something else we can make the other person look retarded! Slashdot wins the day again.

      --
      #fuckbeta #iamslashdot #dicemustdie
    18. Re:Headline epic fails. by Anonymous Coward · · Score: 0

      And [never mind] that QoS is basically congestion-control [...]

      No, it is not.

    19. Re:Headline epic fails. by Forever+Wondering · · Score: 2

      Active queue management [dropping packets] is already being done by most intermediate routers already. It's been done somewhere along the line in getting this reply to you.

      TCP is a "virtual circuit" [stream] protocol. In every TCP packet, there are upstream/downstream byte offsets (e.g. "I've sent you X bytes", "I've received from you Y bytes"). These are examined by the end-to-end nodes only, not any intermediate node or its associated buffers. At this level, packets [per se], dropped or not, don't matter--only byte offsets do.

      If end node A is sending to end node B, and has transmitted X bytes, but has only received an ack from B for X-n, after a time, A will resend X-n to X again. This happens bidirectionally with B to A as well.

      With overly large buffers, B will [eventually] get two [or more] copies of these retransmitted bytes. This just exacerbates the problem, particularly if there are a number of hops between A and B because most of the intermediate buffers become filled with needless retransmit copies [from disparate virtual circuits (e.g. end nodes C and D that are communicating) that have nothing to do with one another other than they must route through the same intermediate node on their way to their distinct destinations].

      The TCP virtual circuit retransmit algorithm assumes that some packets will be lost [due to transmission CRC errors] and/or dropped [or duplicated]. The TCP end-to-end retransmit algorithm [and backoff] is orthogonal to the AQM strategies the articles are talking about. But, large intermediate buffers actually confuse/defeat the TCP backoff strategy and make the problem worse--not better.

      When the AQM algorithms work correctly, most packets aren't dropped, because each transmitting end node [eventually] syncs itself to the maximum rate it can send through the [entire] circuit without having data dropped/replicated/delayed unnecessarily.

      People don't care about "dropped packets". They care about throughput and low latency. If a packet were never dropped, you'd have neither.

      --
      Like a good neighbor, fsck is there ...
    20. Re:Headline epic fails. by NeoMorphy · · Score: 1

      I agree as well. It's a congestion control algorithm that claims to be better than Cubic which is the default used by Linux.

      When trying to find the fastest throughput over a high bandwidth, high latency network I have found Cubic to be much faster than the tcp stack used by AIX and Solaris. I can't even find any reference to AIX or Solaris talking about fixing this issue. And it only needs to be supported from the sender side. So you don't have to worry about what the receiver is using. I know that "fairness" is an issue, but it seems like they can be more aggressive than what they are using now.

      Google "tcp sawtooth" to find the more serious discussions about the problem.

    21. Re:Headline epic fails. by citizenr · · Score: 1

      This is theory, reality is you have > half a second of buffer in the cable modem, this manifests in broken congestion control and high latency when buffer is saturated.

      --
      Who logs in to gdm? Not I, said the duck.
    22. Re:Headline epic fails. by Anonymous Coward · · Score: 0

      You (known idiotic karma whore) vs. the entire AI lab at MIT (known pioneers and scientists). I wonder who has more credibility.

    23. Re:Headline epic fails. by Forever+Wondering · · Score: 1

      This is theory, reality is you have > half a second of buffer in the cable modem, this manifests in broken congestion control and high latency when buffer is saturated.

      Yes, I believe I already covered the effects of overly large buffers [within a network switch].

      However, the cable modem [CM] buffer has far less to do with this. DOCSIS cable modems are a TDM [time division multiplexed] medium. A cable modem may not just transmit upstream data whenever it feels like it. Even with multiple upstream subchannels, a cable system "neighborhood" usually has more subscribers (~500) than it has subchannels.

      Thus, the CM must make a request to the CMTS for an upstream channel and be given a grant. It may then transmit upstream [on that subchannel] for its grant period. The CM needs sufficient data to make the most use of the bandwidth available in its grant TDM slot. A host CPU's NIC just can't respond that fast--hence the pre-buffering. This is physical and/or link layer stuff. That's what the primary use of the CM's [large] buffer is for. To smooth out the inherently bursty nature of the "last mile" of a TDM medium. [*]

      It has almost nothing to do with congestion control mechanisms in the upper protocol layers or queue management in a network switch/router.

      Only end nodes can know the true flow as it depends on the weakest link and the particular routing at the time. A given intermediate node may route one packet, but the next one may be routed by another node. Thus, it has no visibility on the flow [other than its own] in a multihop path. For example, the weakest [slowest] link might be a 9600 baud modem on one end, on a noisy line, that is losing 50% of the data being sent/received. TCP accommodates this well, as I've described previously.

      Network queue management can have some influence on the flow calculations done by end nodes. Before AQM, intermediate nodes would simply fill their [fixed size] buffers, and drop a packet if there was no space. Now that memory's cheap, buffer size isn't a problem, but latency is [particularly, if you're trying to implement QoS]. Also, if there's a "bad actor" (e.g. an end node where the congestion logic is broken due to a bug, or deliberate due to a DDoS attack), AQM can help [proactively] mitigate such behaviors.

      Large buffers [queues] aren't inherently bad. They help in the situation where you get a sudden, brief burst of incoming data. If that's what it is, a short burst, the larger buffer can make things more robust. Just let the data drain normally--no AQM. However, if you get a lot of data continuously that repeatedly exceeds the average drain rate, then you've got a bad actor, and some active queue management is required.

      Pick your mitigation algorithm: The MIT one [yet another instance of MIT's AI lab trying for relevance], the CoDel one, or just a good old "drop every other packet". YMMV ...

      [*] If you're truly P/O'ed by your [own] cable modem latency, try its config page. Or go fiber or DSL, which have no latency at the first hop and can send data at full line rate w/o delay.

      --
      Like a good neighbor, fsck is there ...
    24. Re:Headline epic fails. by Anonymous Coward · · Score: 0

      oh so much training left...

    25. Re:Headline epic fails. by deroby · · Score: 1

      Actually, TCP is all about dropping packets; it's a major part of how it optimises throughput. Software on top of the network layer doesn't get told if (or how many) packets are dropped; it simply reports when it's ready for more.

      --
      If there is one thing to be learned on slashdot, it has to be sarcasm.
  12. they admit they don't know why the system works by Kevin+Fishburne · · Score: 1

    That statement from the summary can't be accurate, unless their definition of "why" is way too specific.

    --
    Buy your next Linux PC at eightvirtues.com
    1. Re:they admit they don't know why the system works by Anonymous Coward · · Score: 0

      Why do you say that? Answering "It works because of machine learning" isn't specific enough, and It's believable that they're unable to say more if they didn't look at the solution.

  13. Singularity? by Arkiel · · Score: 1

    Is this what the singularity looks like?

    1. Re:Singularity? by osu-neko · · Score: 1

      Is this what the singularity looks like?

      Consider it a small sneak preview... ;)

      --
      "Convictions are more dangerous enemies of truth than lies."
  14. Real world data? by Anonymous Coward · · Score: 0

    So is the source in a state where somebody could download it and use it on a real network. Skynet is one thing, but if this can reduce lag in n online game, somebody is going to try it.

  15. Deep sim by mattr · · Score: 1

    Looks interesting. Would be more interesting if possible to model incomplete rollout and rollout at not just endpoints, IPv6 rollout is another rational/superrational mix, and instead we've got ubiquitous NAT instead, right?
        The mention of inability to do an upload during Skype.. is that true?
        Conceivably a whole-network deep simulation could be updated based on real traffic patterns providing suggestions for network upgrades / additional cross connects, so enduser requirements could drive network buildout not carrier profits. That's cool.
          Not sure if the plan is to bake this into hardware and then allow download new firmware as the network evolves, or have some safe code repository that is compiled at endpoints. I can predict a shitstorm over that..

  16. MIT is not the Borg by CuteSteveJobs · · Score: 2, Insightful

    Kudos, but can't OP say "MIT Researchers Keith Winstein and Hari Balakrishnan". Despite the best efforts of their AI labs, MIT is not the Borg. When someone who works for MIT buys an orange juice, "MIT" has not bought an orange juice.

    And if they have software that can outcode me, COOL! How many professions are this lax with job security? :-)

    1. Re:MIT is not the Borg by Anonymous Coward · · Score: 0

      It depends. It's different from sports where the achievement is not dependent on the "organization". Running a marathon is doable without the backers. These are not generic implementations so the credit goes to MIT. Individuals play a very small part in all of that.

    2. Re:MIT is not the Borg by citizenr · · Score: 1

      They cant because outcome was good. They only use names (Star Simpson, Aaron Swartz) when they want to disassociate it from the MIT brand.

      --
      Who logs in to gdm? Not I, said the duck.
  17. The Traveling Salesman Problem by SpectreBlofeld · · Score: 2

    For some reason, while reading the FAQ writeup, the traveling salesman problem sprung to mind. I don't understand either enough to understand why.

    Can anyone educated enough in both issues explain if they are similar computational problems, and why?

    1. Re:The Traveling Salesman Problem by vovick · · Score: 1

      (Disclamer: I'm no expert in routing algorithms or network problems in general)
      Aside from both these problems having to do with finding a path on a graph, I see little similarity. In the TSP you need to find the shortest path to cover all nodes("cities") on a graph, while here you need to find a path between two nodes ("computers") which would both be fast and not cause traffic bottlenecks. I feel there may be many various metrics to define what an "optimal" path should be, each one better in one regard and worse in another (e.g. minimal/average ping, tendency to cause bottlenecks, average router load worldwide, percentage of traffic routed through the NSA headquarters and so on).

    2. Re:The Traveling Salesman Problem by hendrikboom · · Score: 1

      I'll tell you the *big* difference between them.

      One is just trying to find good routing.

      The other has to find the *best* routing.

      -- hendrik

    3. Re:The Traveling Salesman Problem by Anonymous Coward · · Score: 1

      The traveling salesman is different on the net than having a person traveling to sells stuff. The traveling salesman on the net is not a person, it's the overload of fucken ads, pop-ups and spam requiring layers of blocking software. Stop that shit from being dumped on the net at the source because it's like having a clogged sink drain pipe.

    4. Re:The Traveling Salesman Problem by jasax · · Score: 1

      Both can be modeled as finding a path through a network. In the TSP the path is closed (return to the starting node) and must touch all the nodes in the network. The packet travel in the net is more of finding the "best" path (BP) between two network nodes (source and destination). The definition of "best" is somewhat elusive... (faster, touching less number of nodes, using less used links to minimize congestion,...). The TSP is a NP-hard problem regarding algorithmic complexity (I think...), the BP can usually be solved with dynamic programming (in practical cases) and thus is less costly than the TSP in terms of complexity. But the routing problem (and large TSPs, also) is not solved to get the optimal solution, but instead to get an "enough good" solution, using algorithms which can run in reasonable time. And the internet network is so dynamic that when the message "leaves" the source it is not known the path that it will follow to the destination. I think that in the relay nodes the pack is routed "just-in-time" using the info the node has about the traffic in available links...

  18. Come on now by dbIII · · Score: 5, Insightful

    As complex systems goes there are far worse. Go ask an engineer or a scientist.

    1. Re:Come on now by Daniel+Dvorkin · · Score: 5, Interesting

      As complex systems goes there are far worse. Go ask an engineer or a scientist.

      I am a scientist--specifically, a bioinformaticist, which means I try to build mathematical and computational models of processes in living organisms, which are kind of the canonical example of complex systems. And I will cheerfully admit that the internet, taken as a whole, is at least as complex as anything I deal with.

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    2. Re:Come on now by dbIII · · Score: 0

      Then I suggest to go ask an engineer or scientist that does not see the internet as arcane magic. It's nowhere near as complicated as you appear to think.

    3. Re:Come on now by justthinkit · · Score: 2

      Several hundred million computers doing pretty much the same thing is not nearly as complicated as a million species each doing their own thing. The internet is more like a single giant organism.

      --
      I come here for the love
    4. Re:Come on now by Anonymous Coward · · Score: 0

      No one likes you dbill, go away.

    5. Re:Come on now by rthille · · Score: 1

      Yeah, internet is way way more complex than any living organism you deal with...

      because it's composed of all those machines and a crap load of living organisms as well.

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
    6. Re:Come on now by Anonymous Coward · · Score: 0

      Describe it. Go. I'm waiting. While you are at it, tell me what stock will have the best returns tomorrow, as the stock market is only a tiny fraction of the internet. Also, explain what the next slashdot story to break 1k comments is. Again, just a tiny part of the internet.

    7. Re:Come on now by Anonymous Coward · · Score: 0

      keep telling yourself that

    8. Re:Come on now by HiThere · · Score: 1

      He said "taken as a whole". He didn't say the individual small pieces were difficult to understand. And if you don't understand the difference, you don't encourage one to see you as someone who could even potentially understand it...or probably a much simpler system.

      It's sort of like "understanding weather". Small pieces are well understood, but the whole thing... I'm not sure it's even potentially understandable. Are there any reasonable bounds over what you would need to know? Do you need to predict the glactic equivalent of solar winds? Clearly you need to be able to predict nearby novae, but how close is nearby? What about supernovae? I don't know where noise trumps incoming signal, and I suspect that nobody does, because sometimes noise reinforces the incoming signal. (In the brain a certain level of noise improves signal detection.)

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    9. Re:Come on now by parlancex · · Score: 1

      Then I suggest to go ask an engineer or scientist that does not see the internet as arcane magic. It's nowhere near as complicated as you appear to think.

      Exactly! I plug my Internet cable into my Internet box and it's there on my screen. What's more to know?

    10. Re:Come on now by Daniel+Dvorkin · · Score: 1

      The models I build are on the cellular level. There are people working in various kinds of population and ecological modeling, but that's out of my area. I do know that, necessarily, they simplify out a lot of what the individual organisms are doing.

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    11. Re:Come on now by Daniel+Dvorkin · · Score: 1

      I know perfectly well that it's not "arcane magic," any more than living organisms are. It's just a very big, very complex system doing interesting and not-always-predictable things, and well worth studying as such. If you think you have some insight into the behavior of TCP that the MIT researchers lack, by all means you should let them know, or publish it yourself.

      I also know you're a jackass who will do no such thing, just keep talking shit. No further study required.

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    12. Re:Come on now by Anonymous Coward · · Score: 0

      bio...ist usually work on a single specimen clones model so that giant humans machines powered organism is as complex as a the things he deals with....

    13. Re:Come on now by dbIII · · Score: 0

      That's still, to be utterly frank, doing nothing but displaying ignorance, because the entire system is more easily quantifiable than many. Consider how many many different types of cells there are in your own body and the total number of cells in your body for a start. The internet doesn't seem so complex in comparison any more does it?
      IMHO the above attitude is dismissing networking as arcane magic instead of something which while being a complex network is far easier to understand than many other far more complex systems.
      If you want a very simple example I'll give you one from where material science hits biological systems. One of the reasons artificial joints, such as knee replacements, need to be replaced after a few years is due to abrasion of bone in contact with the pins holding it in place which can result in the order of ten to the twenty four tiny bone fragments breaking off in a year. Antibodies interact with this and start attacking bone in place, so eventually another joint has to be attached onto intact bone. Notice that number? Big isn't it? I'm describing a relatively simple system in one joint and there's already a number many orders of magnitude larger than the number of computer systems on the internet.

    14. Re:Come on now by dbIII · · Score: 1

      Don't you dare pretend that the people at MIT wrote something as ignorant as yourself. If you think the internet is a more complex system than even your own body then you do not know much about the subject.

    15. Re:Come on now by Daniel+Dvorkin · · Score: 1

      [snort] Kid, I know a hell of a lot more about my body--and your body, and everyone else's body--than you ever will. And while I'm not nearly as knowledgeable about network engineering as I am about biology and medicine, I know enough to know how complex it is. So do the MIT researchers, for that matter, else they wouldn't be using the approach they are. We don't need genetic algorithms and the like to model simple systems.

      The best thing to do here would be acknowledge that you said something dumb--it's okay, everyone does sometimes--and move on. Instead you're trying to defend an indefensible position, and making a fool of yourself by doing so. Just let it go.

      --
      The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
    16. Re:Come on now by dbIII · · Score: 1

      Kid

      Very amusing from what - a twenty year old? Emotionally retarded thirty maybe at a stretch? Sorry, but your childish bluff isn't working on someone that watched the first moon landing on TV.

      I know enough to know how complex

      Obviously not. See my post elsewhere in this thread that puts things in perspective - ten to the twenty four tiny fragments of bone shed by one artificial knee joint alone for a trivial example of modelling something with vastly more things than there are computers on the planet.

      We don't need genetic algorithms and the like to model simple systems.

      Now you are pretending to be stupid and pretending to misunderstand what I've written in the hope of making it look like I'm suggesting something other than what I am. I am not suggesting that it is a simple system but instead pointing out that there are plenty of other systems that are far more complex.

    17. Re:Come on now by fractoid · · Score: 1

      Maybe you (like I) think living organisms are "arcane magic" and so incredibly complex, but this guy doesn't because he understands them?

      --
      Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
    18. Re:Come on now by dbIII · · Score: 1

      Actually a high school level clue about both supplies enough of a comparison which is why this is so depressing. Of course I've got a bit more than that behind me and I'm coming in from the engineering side. Face it, there's not really a lot of communication protocols and there's not that many different types of devices - and it's a digital system as well. Of course it isn't dead simple but it's not as complex as a single human being either.

    19. Re:Come on now by DG · · Score: 1

      Non sequitur.

      I could counter with the number of packets being transmitted across the entire network in a similar timeframe, or with the total number of electrons in use - but like your bone fragment example - those would be worthless metrics of complexity.

      DG

      --
      Want to learn about race cars? Read my Book
    20. Re:Come on now by DG · · Score: 1

      Kid, he's right; you're wrong. Move on already.

      DG

      --
      Want to learn about race cars? Read my Book
    21. Re:Come on now by dbIII · · Score: 1

      That does not appear to be the case, but I suppose it's fun for people to think that they are gurus of something unimaginable when the reality is far more mundane. Also fuck off with the kid bullshit. I was working as an engineer and had done some materials science research before the first web browser was written, let alone before the NAT hack was thought of.

    22. Re:Come on now by DG · · Score: 1

      Act like a kid, get treated like one.

      --
      Want to learn about race cars? Read my Book
    23. Re:Come on now by dbIII · · Score: 1

      It's depressing that in a place like this that people view a computer network, even a very large and complex one, as magic beyond the understanding of mortals. If I can't express my despair at such cargo cult bullshit here where can I express it?
      If that's seen as "acting like a kid" I think you need to get out more or at least sober up a bit before posting.

    24. Re:Come on now by dbIII · · Score: 1

      If you really think a constructed artifact based on known rules and made up of a very limited number of different parts is as complex as a human body let alone even more complex systems then you've been misled.
      It's worth repeating this: It's depressing that in a place like this that people view a computer network, even a very large and complex one, as magic beyond the understanding of mortals. If I can't express my despair at such cargo cult bullshit here where can I express it?

    25. Re:Come on now by dbIII · · Score: 1

      Nice shift of the goalposts to include the entire fucking universe. You win your petty little mass debating game. Now the rest of us can get back to describing the artifact made of known parts acting in known ways without dismissing it as unknowable magic.

    26. Re:Come on now by DMUTPeregrine · · Score: 1

      Even very simple systems can be beyond the understanding of humans. The logistic map is a simple example of something that can be understood in many ways, but not all. With many initial conditions the output is chaotic and effectively unpredictable. We can make predictions about the long-term behavior, but can't tell exactly what that behavior will be.

      Simple systems can exhibit complex behavior, and complex systems can exhibit simple behavior. The rules of Chess are much more complex than the rules of Conway's Game of Life, yet the Game of Life is far, far more complex than chess. In fact it's Turing-complete, and one could create a chess-playing program within the Game of Life (but not the other way around.)

      There's a difference between something being chaotic and being magical. Neither system would be fully understandable, but the latter is a much more extraordinary claim that no one here has expressed.

      It can be very, very hard to tell if a system can experience chaotic behaviors just by looking at the "rules" of that system. The Horseshoe Map is a piecewise _linear_ system that exhibits chaotic behavior. The rules of the Internet are far more complex, and ruling out all chaotic behavior from them is effectively impossible. One can't conclude that a system is simple just because a system's rules are simple.

      --
      Not a sentence!
    27. Re:Come on now by DMUTPeregrine · · Score: 1

      The Lorenz system is an artifact made of known parts acting in known ways, yet it produces unpredictable outputs. Magic is not involved.

      --
      Not a sentence!
    28. Re:Come on now by dbIII · · Score: 1

      Which relates to digital computers in what what exactly? You've just attempted to shift goalposts along a different axis with a bit of completely unrelated trivia.

    29. Re:Come on now by DMUTPeregrine · · Score: 1

      Well, it was first discovered by doing math on digital computers. Simple systems can have complex behaviors, and complex systems can have simple behaviors. Indeed, mapping the internet by traffic and related content shows fractal-like behavior. The underlying systems are simple, and the resulting entity is exceedingly complex.

      --
      Not a sentence!
    30. Re:Come on now by dbIII · · Score: 1
      Sorry but I think you are stretching the analogy a bit far considering all the things in place that filter out a great deal of the complexity on every device that is receiving and sending signals.

      The underlying systems are simple, and the resulting entity is exceedingly complex.

      That's not the point at issue. Analog or biological systems which are complex to start with or even not completely understood are likely to be even more complex once they are interacting with other things especially when there are no convenient filters in place and other mechanisms which mean devices on a computer network are only interacting directly with a very limited number of nearby hosts. Remember that a packet that originated from the other side of the world has really been recreated from what a more local machine has seen. Anything outside of a very narrow range of rules is not read and not sent out as a new packet.

    31. Re:Come on now by DG · · Score: 1

      What part of "move on already" did you NOT understand?

      DG

      --
      Want to learn about race cars? Read my Book
  19. Famous Last Words by Tablizer · · Score: 1

    "they admit they don't know why the system works"

  20. Re: The blurb is flat out wrong. by Anonymous Coward · · Score: 0

    Congestion control is a core part of TCP. Read a book.

  21. how it actually worked: by Anonymous Coward · · Score: 0

    computer: most of this stuff is useless, sure i'll send it....
    user: wow, so much faster!

  22. know why the system works by l3v1 · · Score: 1

    "they admit they don't know why the system works, only that it goes faster than normal TCP"

    Well, not the best premise for redesigning an infrastructure used by billions. Troubleshooting something you don't quite understand? Right.

    --
    I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
    1. Re:know why the system works by Immerman · · Score: 1

      Hey, we attempt it with the national and global economy all the time, and we don't even have any decent evidence-based models there, much less actual laboratory-controlled experimental data. Just a bunch of wild speculation by economists who want the world to conform to their idea of what should be.

      --
      --- Most topics have many sides worth arguing, allow me to take one opposite you.
    2. Re:know why the system works by Anonymous Coward · · Score: 0

      Someone doesn't understand how genetic algorithms actually work...

  23. Article Explained by Anonymous Coward · · Score: 1

    From the summary:
    Remy is a computer program that figures out how computers can best cooperate to share a network.
    Remy creates end-to-end congestion-control algorithms that plug into the Transmission Control Protocol (TCP). These computer-generated algorithms can achieve higher performance and greater fairness than the most sophisticated human-designed schemes.

    Key limitations are:
    - It's a scheme to generate network-specific algorithms based on the known characteristics of the network devices and network links.
    - Every node in the network needs to run the "optimal algorithm" generated by Remy for that network. If some nodes run "cubic" or some other congestion control algorithm, you won't get optimal output.
    - If some node characteristics or the network topology changes - e.g. you swap your hardware, some node goes down, you need to run the algorithm generation again.

  24. OSPF by globaljustin · · Score: 3, Interesting

    It's basically a more complex version of Open Shortest Path First.

    Depending on how you understand the term 'autonomous system' you can have a lot of fun with the idea. It doesn't *explain* everything about how this works, but it puts it into context, in my mind.

    FTA: To approximate the solution tractably, Remy cuts back on the state that the algorithm has to keep track of. Instead of the full history of all acknowledgments received and outgoing packets sent, a Remy-designed congestion-control algorithm (RemyCC) tracks state variables...

    So basically it has, in the minds of these researchers, a really, really well mapped 'routing table' it can access faster than regular TCP.

    It's a network control algorythm. It optimizes network flow based on user-identified parameters which result in measurable outputs that can give the user feedback.

    Network control algorythm.

    --
    Thank you Dave Raggett
    1. Re:OSPF by Anonymous Coward · · Score: 1

      Control algorythm.

      Algorythm.

      Rythm.

      Soul.

  25. Results are from simulation by Frans+Faase · · Score: 1

    If you read the page, you will see that the results are from a simulation and not based on experiments in a real network. And the given performance only works under certain stable conditions. Some remarks seem to imply that if you are moving around (like with a mobile device) the results no longer apply. Still, I believe that machine learning techniques could out perform human coded algorithms, but probably not as much as the 'theoretical' results presented in this research/paper.

    1. Re:Results are from simulation by Skapare · · Score: 1

      Then we should find some human somewhere, lock him/her to a desk with a computer, and force him/her to write the code to re-implement TCP. Then compare the performance with the AI produced algorithm.

      --
      now we need to go OSS in diesel cars
  26. ... but if it breaks, who's going to fix it? by Anonymous Coward · · Score: 0

    More Intelligent Troubleshooters

  27. when AI breaks the computer hacking law? by Anonymous Coward · · Score: 0

    then what? you cant threaten it with 30 years in prison like they did Aaron Swartz

  28. NOT machine learning (YAMH) by dltaylor · · Score: 3, Interesting

    Yet Another Misleading Headline

    The paper states quite clearly that once the simulation has produced an algorithm, it is static in implementation.

    The authors give a set of goals and an instance of a static network configuration and run a simulation that produces a send/don't send algorithm FOR THAT NETWORK, in which all senders agree to use the same algorithm.

    While this looks like very interesting and useful research, it has nothing to do with systems that learn from and adapt to real world networks of networks.

    1. Re:NOT machine learning (YAMH) by Anonymous Coward · · Score: 0, Interesting

      This.

      I've done some work in machine learning and was wondering if they'd done something novel. Then I read through and it said that it was very good for its given training set but the performance drops off rapidly the further the network strays from said training set.

      Well hell. I've had machine learning algorithms that were 100% accurate when working on its training set. That's not impressive. The test comes in to how well it works when presented a data point outside of its training set. And they state in the FAQ that it doesn't do particularly well.

    2. Re:NOT machine learning (YAMH) by Nemyst · · Score: 3, Informative

      Um, what? It most certainly is machine learning. Your "simulation" is an offline machine learning algorithm which, given input parameters, finds the best algorithm in the situation provided. Machine learning isn't strictly online algorithms, and it most certainly isn't "systems that learn from and adapt to real world networks of networks", which I'm having a hard time even parsing.

    3. Re:NOT machine learning (YAMH) by rdnetto · · Score: 1

      From the article:

      This isn't like a machine learning task where we collected a limited corpus of real data and then we're trying to make statements about our ability to perform on future data, yet-to-be-collected.

      My (rather limited) understanding of it is that within the field (i.e. to people who actually know what they're talking about), the phrase 'machine learning' refers to the above case; using a training set of real data to develop a model, then applying that model to real problems.

      In contrast, Remy takes a (stochastic) traffic model, rather than raw data, which would make it a different kind of AI.

      --
      Most human behaviour can be explained in terms of identity.
  29. I know why by PainPoint · · Score: 1

    I know why it works...

  30. Re:The blurb is flat out wrong. by paithuk · · Score: 4, Informative

    The blurb says it "redesigns TCP/IP", and the article itself specifically says "congestion control". Which is NOT part of TCP/IP design. Congestion control is a routing feature.

    Seriously, it's both incredible how wrong you are with that statement and that somebody rated it as informative. I suggest you read up on the subject: http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm http://en.wikipedia.org/wiki/Congestion_window http://tools.ietf.org/html/rfc5681

  31. Increasing Wireless Network Speed By 1000% by figleaf · · Score: 1

    Wonder if can be combined with a previous invention : Boosting the performance of wireless networks by up to 10 times

  32. High frequency trading anyone? by Anonymous Coward · · Score: 0

    High frequency trading is one of those areas where things like genetic algorithms work without people knowing why.

    Of course, this delivers occasional stock crashes.

    Now make the the whole internet use non-linear algorithms like that to improve its operation. It will work. Until it doesn't.

  33. Complexity From Simplicity by Anonymous Coward · · Score: 0

    Boole's work was brought back from the grave because it eased modelling railroad networks, which had become almost unanageable and uncontrollable, and were a essential to the military planning and strategy of the time. Then, came other timed logic networks.

    Competition. Evolution. Cooperation. Pest control. Disease control. Relative minima.

    Couldn't help noticing that, with smart everything, they now have access to your TVs, washing-machines, paper shreders, temperature control, biometric locks, garage door, ...

  34. Fixing open-source drivers this way... by Electricity+Likes+Me · · Score: 1

    I've always wondered why we couldn't use this approach to fix certain types of open-source drivers. We know the APIs, and we have the hardware - set it up and get machines to iterate over it until we get the desired properties for hardware which doesn't need a human their to verify its functioning correctly. I'm thinking for something like network drivers this could work - though you could imagine a system which did it for graphics cards too.

    1. Re:Fixing open-source drivers this way... by LWATCDR · · Score: 1

      You would want to create a virtual version of the hardware to do this. The problem with systems like this is that they may exploit hardware quirks and only work on one card or chip. Of course you would then want to test on a few pieces of real hardware to make sure your simulation is accurate.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  35. Just a (probably suicidal) thought by Anonymous Coward · · Score: 0

    Has any of those guys just thought of, y'know, putting those machine learning algos THROUGH themselves so they get better at learning?
    Someone call the Ghostbusters, we have a ghost in the shell, and he knows all.

    Ha, you thought I was going to make a Terminator joke, didn't you?
    Don't worry, I'll be back.

  36. So what? by Hentes · · Score: 1

    We don't use TCP because it's particularly efficient, but because it has been the standard for decades. With our current knowledge, humans could also design faster protocols, we just don't want to waste our time, seeing that not even IPv6 has managed to become adopted.

    1. Re:So what? by NeoMorphy · · Score: 1

      We don't use TCP because it's particularly efficient, but because it has been the standard for decades. With our current knowledge, humans could also design faster protocols, we just don't want to waste our time, seeing that not even IPv6 has managed to become adopted.

      Actually they have been designed. I know there are some that use UDP to encapsulate the faster protocols. Unfortunately you need to install it on both the sender and receiver. But if you have a congestion avoidance algorithm that can perform faster you only have to support it from the sender side.

  37. I don't see the problem. by Anonymous Coward · · Score: 0

    Learning algorithm are good at finding a local optimum and save you from theorizing and writing a algorithm based on your theory, that can be wrong. The algorithm automatically solve the problem for you.

  38. code generators beat humans by Anonymous Coward · · Score: 0

    Their code doesn't need to be readable, maintainable, and if ineligant code gets a better result then that's what you get.

  39. Heuristic Networking by Tempest451 · · Score: 1

    Sounds like application-based routing algorithms that allow programs to design specific routing patterns on the fly.

  40. Game Theory by PPH · · Score: 1

    Does Remy assume cooperation with other network users or competition for a scarce resource? If I tune my TCP algorithms but others do not, who wins?

    One positive aspect: This could keep SkyNet busy competing against other systems rather than turning on the human race. Until it realizes that the network could be speeded up by eliminating all the meatbags downloading porn.

    --
    Have gnu, will travel.
    1. Re:Game Theory by NeoMorphy · · Score: 1

      You will win! Just don't go too crazy. If they notice network response issues they might notice your ip address in the top ten in network traffic throughput. They can then drill down and graph the amount of unacknowledged data in-flight. They might get suspicious when they observe the shape doesn't look like your typical saw-tooth graph. Sounds like work, but if they have a tool like OpNet, it's only a couple of mouse clicks.

  41. Apply science to your own creation by Anonymous Coward · · Score: 0

    If they don't know how it works, stop being engineers and become scientists. We don't know how cells work, so we do science on them. Doing science on a piece of software seems like it should be easier.

  42. ATTENTION by ArcadeMan · · Score: 1

    Warn: There is another system

  43. It already chose by DG · · Score: 1

    It likes cats.

    DG

    --
    Want to learn about race cars? Read my Book
  44. MIT Uses Machine Learning Algorithm To Make TCP Tw by Anonymous Coward · · Score: 0

    oooh, wonder if it can solve cold fusion too.

  45. Teaching a computer to play Mario seemingly throu by Anonymous Coward · · Score: 0

    Teaching a computer to play Mario seemingly through voodoo

    http://www.cs.cmu.edu/~tom7/mario/

  46. Tell the Chinese! by Anonymous Coward · · Score: 0

    That is poly-fucking-morphic code, polymorphic code, LIKE VIRUS, THE FUCK UP AND LAID! poly-fucking-morphic code!

  47. Calling your bluff by dbIII · · Score: 1

    So then, where is an example of this chaotic behaviour in nice neat and frequently filtered digital outputs from digital computers?
    I suggest thinking instead of falling for the cargo cult bullshit.