No, I didn't. With 100 packets out, 5 drops means 5 more packets have to go out:: 105 packets to carry 100 packets of content. (this assumes an efficient tcp stack that will correctly queue and reassemble out of sequence packets.) Yes, those drops will slow throughput by any annoying amount. However, the alternative, FEC, adds a rather large amount of overhead to every single packet. At one end of the spectrum, this overhead accounts for a large amount of throughput. (eg. on a fairly clean path) At the other end, throughput will be crap - period - because of the extreme high loss rate. In this case, smaller packets would better than a boatload of error correction data. (eg, DSL interleaved mode)
They're adding error-correction at layer-3+ because they cannot add it to the media layer (i.e. correct a broken/unstable LTE network) where it belongs. They want to pack more data into each packet in the hopes that it's one of the xx% that actually gets through. It may ultimately improve throughput ("goodput") on a broken network, but it's not going to reduce the amount of total traffic -- it will, in fact, increase it, a lot. And it's an increase for *everyone*, *all the time*. (how much "fec" does it take to recreate a 1500byte packet? or 512B? All because your carrier is dropping 5 out of 100 packets. Let's say 33% FEC overhead; that's 133 packets to carry what would otherwise be 100 packets of data. Without FEC, you had to send 105 packets for every 100 packets.)
TCP (esp. HTTP) already does most of what they're recreating in QUIC... encryption: check (SSL), compression: check (deflate), congestion control: long list of CHECK, multiplex stream: check (multicast), FEC: not necessary (and QUIC isn't doing it yet)
"packet loss rate"? That depends entirely on what's causing the loss. If you receive packet 1, then packet 3, and never see any piece of packet 2, unless you've devoted a significant amount of space for FEC (that covers more than just the current packet, i.e. the next packet...) then packets 1 and 3 will not be enough to create packet 2 -- esp. when packets can be variable size. HOWEVER, if you are receiving a partially corrupted packet 2, then any error-correction contained within it may allow it to be fixed. But then, any Network Engineer(tm) will quickly tell you're correcting errors at the wrong place: you are correcting a layer2 or layer1 problem at layer 3. In other words, if you are seeing corrupt IP packets, your network is broken. RF technologies ALREADY implement [F]EC because they are known to be operating over a noisy unstable medium. (ATSC (ota tv), 8VSB (us cable tv), DSL, DOCSIS, 2G, 3G, 4G, DVB-everything, etc., etc., etc. Hell, even FIBER has error-correction, and that's the most stable medium we have.) FEC at layer 3 is, stupid.
Forward error correction, requires foreknowledge of data. In order to send packet 1, I have to already have packet 2, which means a data stream has to be delayed by at least one packet. This works for things like voice and video, because a delay of one small, fixed size frame is unnoticeable by a human. For HTTP, this might work for all but the last packet of a response (with padding), but requests are usually far too small.
To be fair, they did test the flammability of the materials. They just didn't do it right... in a pressurized O2 environment. After the fire, they did the tests correctly, and to their horror, found several things to be "highly flammable". (the glue on the back of the massive amount of Velcro for one)
The inward opening hatch was to improve safety in space, where, under no circumstances do you want that door to have any way of accidentally opening.
And costs 3-4x as much as road taxed gas. So it's not wise to run that on the road anyway. (btw, you can tell who's running "race fuel" by the exhaust smell. I don't know how many cops would notice.)
The ruling explains there were others working on the project, but a) Childs didn't like sharing -- in his eyes, everyone's a moron, and b) Ybanez, who had been working with him, was moved to a different project for months leaving just Childs to run everything. When brought back to the project, he refused to provide access because he didn't want Ybanez giving the password(s) to anyone else. On top of that, he went full-on-rogue-sysadmin locking down access to only his select PC(s), disabling local access (console), erasing startup configs, disabling password recovery, and keeping the sole set of archived configs encrypted in his own possession. Despite having acknowledged the FiberWAN design as city property, and knowing full well disclosure was forbidden by Homeland Security, the arrogant ass twice submitted the plans for copyright registration -- claiming he didn't know they'd be public documents.
In light of all that, 4 years and 1.5mil$ is not a punishment. This fool should be taken out and shot. We may look at the $646,000 figure for a full audit and think it's excessive, but that ignores the level to which Childs went to be "King of the Mountain"; you cannot trust a single thing in the entire network. Even line of configuration has to be verified. Every single device, wire, screw, and power cord has to be documented and inspected. (who knows what he might have taped under a desk or floor tile or inside a wall.)
Recovery at that point is an nvram erasure. (Or, disassemble the device to externally recover the NVRAM -- on systems where it's removable. Or replace the bootrom with a custom one that ignores that setting (i.e. pay Cisco an assload of money) -- where the bootrom is removable.)
And his second trick... not saving a startup-config. Reset the device and it powers back up blank! And you have no documentation on how it was configured.
They knew before he was fired. Some of his bosses (at least his immediate boss) were aware of his "process" and went along with it. As I recall, the shit started flowing when a new boss got in the tree somewhere(?), and Childs was moved to a different department where his childishness became overly apparent, and far more than anyone could overlook.
Actually, they continued to use the network just fine despite the sole password holder being in jail.
The big point was, they were unable to have anyone else manage the network: had something broken, it would've stayed broken; any changes needed could not be done. To make matters more interesting, there was no known documentation for the network; some devices had password recovery disabled (they'll reboot cleanly, but you won't get into them without erasure), and other devices had no startup config (they won't reboot)... good luck guessing which is which -- guess wrong and you have a router with no config and no knowledge of how to reconfigure it. He did this intentionally to prevent people he saw as completely incompetent (i.e. everyone) from messing with his baby. He genuinely thought by withholding the password(s), they would "see the error of their ways" and give him his job back.
In any sane enterprise, it never would have gotten to such a point. The wack-job would've been fired long before he took the entire infrastructure hostage. (which was the case long before his termination.) He's a nut, pure and simple; everyone who's had more than 5s to look at the case knew exactly where this was going. The only thing that bugs me is the fact that the managers who allowed this mess to grow aren't even mentioned, much less held accountable for it.
Except he didn't take the keys to a truck, he took the keys to all the trucks. One truck... easy enough to deal with. Thousands of trucks that people are currently driving... not quite so easy to recover.
Actually, it's more like 1.5s. (based on a BGAN system in my driveway. 1.2s from the walmart parking lot -- wide open sky) It's the most expensive internet I know of, but it works f'ing everywhere. (Antarctica not included.)
Ah, because it wasn't so simple then. It took some truly massive industrial works to get the fissionable material in the first place, and a lot of math (not done by computers) to come up with theoretical designs, that then had to be tested and refined. Today, we have a much better understanding of the process, and computers capable of extremely detailed and accurate simulations. (not that we've tested any designs for years.)
This assume the computer at the other end of that button is going to do what it's supposed to. Unless there are aux hardware controls on that button to disconnect power from the ECU, you're putting a lot of trust in a malfunctioning ECU.
(And yes, does select a gear... forward or reverse.)
Yes. And you should hire "her" without a face-to-face interview, or an actual background check. (and given the apparent nature of the job, a security check / validate "her" security clearance.)
It's not unheard of. But a few google searches or a single phone call could've answered that one. (It's hard to attend MIT and not leave an internet fingerprint.)
Slashdot Mirror
No, I didn't. With 100 packets out, 5 drops means 5 more packets have to go out :: 105 packets to carry 100 packets of content. (this assumes an efficient tcp stack that will correctly queue and reassemble out of sequence packets.) Yes, those drops will slow throughput by any annoying amount. However, the alternative, FEC, adds a rather large amount of overhead to every single packet. At one end of the spectrum, this overhead accounts for a large amount of throughput. (eg. on a fairly clean path) At the other end, throughput will be crap - period - because of the extreme high loss rate. In this case, smaller packets would better than a boatload of error correction data. (eg, DSL interleaved mode)
If you have a cord... pull cord, then pull battery(s).
Unless you configure your shutdown button to actually shutdown the machine instead of hibernate. (Note: it's been like this since Vista, btw)
Actually, packet pacing is *REQUIRED* for UDP if you want your packets to arrive even remotely in the order they were sent.
They don't check them for TCP either. TCP handshake breaks if you lie about your address, 'tho. For a SYN flood attack, it doesn't matter.
They're adding error-correction at layer-3+ because they cannot add it to the media layer (i.e. correct a broken/unstable LTE network) where it belongs. They want to pack more data into each packet in the hopes that it's one of the xx% that actually gets through. It may ultimately improve throughput ("goodput") on a broken network, but it's not going to reduce the amount of total traffic -- it will, in fact, increase it, a lot. And it's an increase for *everyone*, *all the time*. (how much "fec" does it take to recreate a 1500byte packet? or 512B? All because your carrier is dropping 5 out of 100 packets. Let's say 33% FEC overhead; that's 133 packets to carry what would otherwise be 100 packets of data. Without FEC, you had to send 105 packets for every 100 packets.)
TCP (esp. HTTP) already does most of what they're recreating in QUIC... encryption: check (SSL), compression: check (deflate), congestion control: long list of CHECK, multiplex stream: check (multicast), FEC: not necessary (and QUIC isn't doing it yet)
"packet loss rate"? That depends entirely on what's causing the loss. If you receive packet 1, then packet 3, and never see any piece of packet 2, unless you've devoted a significant amount of space for FEC (that covers more than just the current packet, i.e. the next packet...) then packets 1 and 3 will not be enough to create packet 2 -- esp. when packets can be variable size. HOWEVER, if you are receiving a partially corrupted packet 2, then any error-correction contained within it may allow it to be fixed. But then, any Network Engineer(tm) will quickly tell you're correcting errors at the wrong place: you are correcting a layer2 or layer1 problem at layer 3. In other words, if you are seeing corrupt IP packets, your network is broken. RF technologies ALREADY implement [F]EC because they are known to be operating over a noisy unstable medium. (ATSC (ota tv), 8VSB (us cable tv), DSL, DOCSIS, 2G, 3G, 4G, DVB-everything, etc., etc., etc. Hell, even FIBER has error-correction, and that's the most stable medium we have.) FEC at layer 3 is, stupid.
Forward error correction, requires foreknowledge of data. In order to send packet 1, I have to already have packet 2, which means a data stream has to be delayed by at least one packet. This works for things like voice and video, because a delay of one small, fixed size frame is unnoticeable by a human. For HTTP, this might work for all but the last packet of a response (with padding), but requests are usually far too small.
To be fair, they did test the flammability of the materials. They just didn't do it right... in a pressurized O2 environment. After the fire, they did the tests correctly, and to their horror, found several things to be "highly flammable". (the glue on the back of the massive amount of Velcro for one)
The inward opening hatch was to improve safety in space, where, under no circumstances do you want that door to have any way of accidentally opening.
Buy a plugin prius and add one of the aftermarket uber-battery packs.
And costs 3-4x as much as road taxed gas. So it's not wise to run that on the road anyway. (btw, you can tell who's running "race fuel" by the exhaust smell. I don't know how many cops would notice.)
Disable password-recovery and tell me how far you get. Go ahead. I'll wait...
The ENTIRE point is to prevent someone from gaining unauthorized access to the system. (old platforms don't support this.)
The ruling explains there were others working on the project, but a) Childs didn't like sharing -- in his eyes, everyone's a moron, and b) Ybanez, who had been working with him, was moved to a different project for months leaving just Childs to run everything. When brought back to the project, he refused to provide access because he didn't want Ybanez giving the password(s) to anyone else. On top of that, he went full-on-rogue-sysadmin locking down access to only his select PC(s), disabling local access (console), erasing startup configs, disabling password recovery, and keeping the sole set of archived configs encrypted in his own possession. Despite having acknowledged the FiberWAN design as city property, and knowing full well disclosure was forbidden by Homeland Security, the arrogant ass twice submitted the plans for copyright registration -- claiming he didn't know they'd be public documents.
In light of all that, 4 years and 1.5mil$ is not a punishment. This fool should be taken out and shot. We may look at the $646,000 figure for a full audit and think it's excessive, but that ignores the level to which Childs went to be "King of the Mountain"; you cannot trust a single thing in the entire network. Even line of configuration has to be verified. Every single device, wire, screw, and power cord has to be documented and inspected. (who knows what he might have taped under a desk or floor tile or inside a wall.)
(wireless key. I've often wondered what happens if I chuck the key out the window as I'm driving along.)
Cisco IOS: no service password-recovery
Recovery at that point is an nvram erasure. (Or, disassemble the device to externally recover the NVRAM -- on systems where it's removable. Or replace the bootrom with a custom one that ignores that setting (i.e. pay Cisco an assload of money) -- where the bootrom is removable.)
And his second trick... not saving a startup-config. Reset the device and it powers back up blank! And you have no documentation on how it was configured.
They knew before he was fired. Some of his bosses (at least his immediate boss) were aware of his "process" and went along with it. As I recall, the shit started flowing when a new boss got in the tree somewhere(?), and Childs was moved to a different department where his childishness became overly apparent, and far more than anyone could overlook.
Actually, they continued to use the network just fine despite the sole password holder being in jail.
The big point was, they were unable to have anyone else manage the network: had something broken, it would've stayed broken; any changes needed could not be done. To make matters more interesting, there was no known documentation for the network; some devices had password recovery disabled (they'll reboot cleanly, but you won't get into them without erasure), and other devices had no startup config (they won't reboot)... good luck guessing which is which -- guess wrong and you have a router with no config and no knowledge of how to reconfigure it. He did this intentionally to prevent people he saw as completely incompetent (i.e. everyone) from messing with his baby. He genuinely thought by withholding the password(s), they would "see the error of their ways" and give him his job back.
In any sane enterprise, it never would have gotten to such a point. The wack-job would've been fired long before he took the entire infrastructure hostage. (which was the case long before his termination.) He's a nut, pure and simple; everyone who's had more than 5s to look at the case knew exactly where this was going. The only thing that bugs me is the fact that the managers who allowed this mess to grow aren't even mentioned, much less held accountable for it.
Except he didn't take the keys to a truck, he took the keys to all the trucks. One truck... easy enough to deal with. Thousands of trucks that people are currently driving... not quite so easy to recover.
Actually, it's more like 1.5s. (based on a BGAN system in my driveway. 1.2s from the walmart parking lot -- wide open sky) It's the most expensive internet I know of, but it works f'ing everywhere. (Antarctica not included.)
Ah, because it wasn't so simple then. It took some truly massive industrial works to get the fissionable material in the first place, and a lot of math (not done by computers) to come up with theoretical designs, that then had to be tested and refined. Today, we have a much better understanding of the process, and computers capable of extremely detailed and accurate simulations. (not that we've tested any designs for years.)
No, the fundamental reason for speed limits is, in fact, safety. However, enforcement generates so much income that the true intent was lost long ago.
This assume the computer at the other end of that button is going to do what it's supposed to. Unless there are aux hardware controls on that button to disconnect power from the ECU, you're putting a lot of trust in a malfunctioning ECU.
(And yes, does select a gear... forward or reverse.)
Yes. And you should hire "her" without a face-to-face interview, or an actual background check. (and given the apparent nature of the job, a security check / validate "her" security clearance.)
It's not unheard of. But a few google searches or a single phone call could've answered that one. (It's hard to attend MIT and not leave an internet fingerprint.)
Say it with me, children: D A R K M A T T E R
(seems to be the answer to every incorrect formula.)