Interesting. So what you're saying is: as equipment, you need a skeptical audience of scientists and engineers who can suggest testable explanations for what you record, and then you need to go back and put them to the test. You've only found something "weird" if you can eliminate the testable explanations.
Wacky. According to your link, it gained an order of magnitude in weight in from 1999 to 2000 when the aluminum ball was replaced with a crystal ball (150 lbs to 1200 lbs) and then it gained another order of magnitude in weight when it was replaced with a larger crystal ball between 2008 and 2009 (1200 lbs to 12000 lbs).
When I go to a technical conference, I expect the lecture hall to have tables, power strips and wifi. And the gentle patter of folks tapping laptop keyboards sounds little different than rain.
Now, I pay a lot of money to attend these conferences, but the simple truth is that a portion of the information is rubbish, a portion of it I can collect half-listening and only a portion of it requires my full attention. I'm not trying to diss the lecturers; it's just that I'm there to fill in gaps in my knowledge, not learn the entire subject fresh off the boat.
We didn't have notebooks when I was in college. But if we had, I fail to see how someone gently typing on a keyboard is any worse than the guy snoozing or the gal reading a novel. Handle it the same way: if the reader is chuckling, the snoozer snoring or the gamer grunting and bashing the keyboard, send them away. Otherwise leave them alone and assume that they're gathering the pieces of your lecture that they're here to learn.
Worse than that, actually. The methodology assumes that one wrong multiple-guess answer is as likely as any other wrong multiple-guess answer. But that isn't the case. Wrong answers are often chosen specifically because a particular and expected form of mistake will yield that answer. This skews the results to a point where the real chance of two people in a class getting exactly the same wrong answers could be as little as 1 in 100... and when you give test after test, it doesn't take long for 1 in 100 odds to produce a "winner" by pure random luck.
If you're good at programming, you program frequently. Even with the knack, doing it a lot is the only way to get good. If you program frequently then you type a lot -- and in doing so become fast at it.
Cook and Atwood are both right. Cook correctly observes that your ability to program does not in any way depend on your ability to type quickly. Atwood correctly observes that that typing speed is a gambler's "tell:" if you haven't programmed enough to get fast at typing then however convincingly you talk the talk, odds are against you being very good at programming.
As more ISPs deploy LSN systems, the effectiveness of these IPv4 filtering systems will be hurt.
That doesn't follow. The folks in dynamic space (the same space that will be served by LSNs) are already considered spammers when they connect to a non-local SMTP server. The only reason they're scored instead of outright blocked is that there's no rigorous list of what is and isn't a dynamic space. It makes no difference to the server whether it filters a range of IPs or a single IP.
Identifying the individual spammer from an abuse report is slightly more difficult, but only slightly. And if you're behaving like a good net citizen, you probably blocked outbound 25 at the LSN box to begin with so you're not getting any reports because your virus-laden customers aren't able to successfully spam.
Without javascript we'd have an html browser and a Flash browser and when I wanted a newspaper or message board, I wouldn't expose my machine to the risk associated with the Flash browser.
One thing I've been trying to figure out, what exactly is going to happen in the next year or so?
Short answer: NAT.
Lots and lots of perfectly good IP addresses have been deployed in use scenarios which would work perfectly well using RFC 1918 addresses aggregated behind a single public-facing IP address. When you need more IP addresses for a high-value application, you'll raid the places employing them in a low-value application.
IANAL, but here's some perspective from someone who has been in the thick of the ARIN policy process for the last few years:
First, you're talking about RIPE (european IP addresses) while the article is about the registration services process at ARIN (north american IP addresses).
Had you been talking about ARIN, this is frankly the kind of thing where you'll want to sign the LRSA and soon. ARIN will work with you to nail down the details and confirm the registration but they'll want to normalize their relationship with you via a signed contract first. I think they'll still update if you come to them with ironclad documentation, but if you had ironclad documentation you'd have been the kind of person who kept the registration up to date to begin with.
For those who are still contactable via at least the email address published on the registration, now is not the time to sign the LRSA. ARIN claims you have more rights under the LRSA than under the regular RSA but on close examination the claim doesn't really hold up. It's a standard adhesion contract in which the powerful party has reserved the rights to themselves.
That having been said, keep tabs on proposed ARIN policy every 6 months or so. ARIN probably won't seek the legal liability from trying to seize legacy registrations that are obviously in use, but the situation could change.
If you are in the situation where your contact details are dead, I personally think you SHOULD sign the LRSA and normalize things with ARIN. A/24 is going to be worth at least $1000 within 12 months, and probably a lot more. IPv6 won't deploy fast enough, the IPv4 free pool will be gone by mid year and the only source of new IPv4 addresses will be folks who are willing to sell.
On the other side, the unrouted dead registrations without valid contacts are very likely to evaporate in the next 24 months. The ARIN policies for this sort of reclamation aren't in place yet, but mark my words: they will be.
Yeah, exactly. I used and liked proftpd back in the day, but why is anyone still using an FTP server for anything? The protocol is not secure or reasonably securable. Come on folks, the writing has only been on the wall for 15 years now...
Make that 30 days if you want network security folk not to laugh at you. 365 if you want any support from law enforcement. Better yet, change your focus to a "do not sell list" where passing a standardized header serves as legal notice that the receiving server is forbidden from sharing any information about the transaction with a third party, specifically or in aggregate. You won't get that either, but at least your only opposition would be from marketing folk.
Barring plugins with cookie-like features and actual tracking software you've elected to install, it's actually pretty hard to separate out your traffic from everybody else's.
You can keep track of a linear session by passing state in the URL but you lose it as soon as the guy goes somewhere else and comes back. You can do some fuzzy matching based on behavioral patterns but it takes a lot of computing power and the confidence drops off quickly.
Worked in the biz for a little while. The core data came from folks incentivized to knowingly install tracking software on their PCs *and* take surveys because trend data with demographics was much more valuable that trend data without. The data captured from network taps was mostly useful as a tool for correcting the statistical skew in the higher quality data.
Right... So as a guy running a web server I'm supposed to "forget" about you probing my server trying to break in because you have the "Don't track me" header set.
We already have such a setting. Tools->Options->Privacy->Uncheck "Accept cookies." Some web sites work with it unchecked. Some don't. Make your choice whether you want their content.
Not exactly. Most ISPs filter their customers announcements that way, but its highly impractical to implement such filters when peering with other ISPs.
The solution boils down to:
1. Temporary filter installed for errant routes 2. Peering POC at source ISP gets a stern lecture and a depeering threat 3. Peering is so valuable (and so costly to lose) that peering POC smacks around the person who allowed the leak in the first place. 4. Mistake repeats because the staff who originally allowed it are incompetent 5. Source ISP gets depeered so he has to pay for all his Internet traffic via a connection that actually is filtered 6. Source ISP fires the fool who screwed up in the first place, cancels the customer contract (if it was customer originated). 7. Source ISP most likely never recovers and ends up being bought out while in or near bankruptcy.
Okay, so steps 4 onward are an artful exaggeration. But seriously, senior network engineers get really bent out of shape when a peer slips them a bum route.
Had you just quoted a standards document says "Here's how it's supposed to be done and now we'll offer some suggestions for all of you who decide not to do it this way" I'm not so sure I'd be quick accuse you of being the source of any cognitive dissonance.
TCP first defined in RFC 793. No slow start; implementations generally send segments up to the window size negotiated in SYN exchange which is generally the smaller of the speakers' two buffers.
Slow start first referenced in RFC 1122 (Internet host requirements) as: ''Recent work by Jacobson [ACM SIGCOMM-88] on Internet congestion and TCP retransmission stability has produced a transmission algorithm combining "slow start" with "congestion avoidance". A TCP MUST implement this algorithm.''
At this point in the process there does not appear to be an RFC specifying TCP slow start making this statement in a document that is not itself about TCP per se very dubious.
A decade later, RFC 2001 says: "Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery." The word "must" is subsequently used in connection with congestion avoidance but is not used in connection with slow start.
RFC2414 then revisits the question of TCP's initial window size selection referencing RFC 2001 but again declines to state that TCP "must" start with a small window.
RFC 2581 finally sets an unambiguous slow start requirement: The slow start and congestion avoidance algorithms MUST be used by a TCP sender [...] IW, the initial value of cwnd, MUST be less than or equal to 2*SMSS bytes and MUST NOT be more than 2 segments.
However, even as it does so, it goes on to comment that, "We note that a non-standard, experimental TCP extension allows that a TCP MAY use a larger initial window [...] We do NOT allow this change as part of the standard defined by this document. However, we include discussion [...] in the remainder of this document as a guideline for those experimenting with the change, rather than conforming to the present standards for TCP congestion control."
In other words, even though out of the box TCPs MUST implement slow start, it's understood that other behaviors are in use and are expected to continue.
Finally, RFC 3390 allows the out-of-the-box behavior of TCP to use a larger initial window than 2581.
IETF uses the capitalized MUST/MUST NOT terminology for a reason. It's used anywhere an implementer could reasonably do something else but for some reason isn't allowed to. Where it isn't present, it isn't required. If the authors omitted that terminology even after referencing RFC 2119 in a standards track modification to such a widely used protocol, they did so because the entire modification is optional.
Slashdot Mirror
Interesting. So what you're saying is: as equipment, you need a skeptical audience of scientists and engineers who can suggest testable explanations for what you record, and then you need to go back and put them to the test. You've only found something "weird" if you can eliminate the testable explanations.
I don't want to switch from Verizon Wireless. The Nokia N900 looks awesome but it's a GSM phone. Any suggestions for a good SSH phone on Verizon?
I didn't get it from what the article said. I got it from observing similar systems and then looking to see what the article didn't say.
Wacky. According to your link, it gained an order of magnitude in weight in from 1999 to 2000 when the aluminum ball was replaced with a crystal ball (150 lbs to 1200 lbs) and then it gained another order of magnitude in weight when it was replaced with a larger crystal ball between 2008 and 2009 (1200 lbs to 12000 lbs).
When I go to a technical conference, I expect the lecture hall to have tables, power strips and wifi. And the gentle patter of folks tapping laptop keyboards sounds little different than rain.
Now, I pay a lot of money to attend these conferences, but the simple truth is that a portion of the information is rubbish, a portion of it I can collect half-listening and only a portion of it requires my full attention. I'm not trying to diss the lecturers; it's just that I'm there to fill in gaps in my knowledge, not learn the entire subject fresh off the boat.
We didn't have notebooks when I was in college. But if we had, I fail to see how someone gently typing on a keyboard is any worse than the guy snoozing or the gal reading a novel. Handle it the same way: if the reader is chuckling, the snoozer snoring or the gamer grunting and bashing the keyboard, send them away. Otherwise leave them alone and assume that they're gathering the pieces of your lecture that they're here to learn.
Worse than that, actually. The methodology assumes that one wrong multiple-guess answer is as likely as any other wrong multiple-guess answer. But that isn't the case. Wrong answers are often chosen specifically because a particular and expected form of mistake will yield that answer. This skews the results to a point where the real chance of two people in a class getting exactly the same wrong answers could be as little as 1 in 100... and when you give test after test, it doesn't take long for 1 in 100 odds to produce a "winner" by pure random luck.
If you're good at programming, you program frequently. Even with the knack, doing it a lot is the only way to get good. If you program frequently then you type a lot -- and in doing so become fast at it.
Cook and Atwood are both right. Cook correctly observes that your ability to program does not in any way depend on your ability to type quickly. Atwood correctly observes that that typing speed is a gambler's "tell:" if you haven't programmed enough to get fast at typing then however convincingly you talk the talk, odds are against you being very good at programming.
As more ISPs deploy LSN systems, the effectiveness of these IPv4 filtering systems will be hurt.
That doesn't follow. The folks in dynamic space (the same space that will be served by LSNs) are already considered spammers when they connect to a non-local SMTP server. The only reason they're scored instead of outright blocked is that there's no rigorous list of what is and isn't a dynamic space. It makes no difference to the server whether it filters a range of IPs or a single IP.
Identifying the individual spammer from an abuse report is slightly more difficult, but only slightly. And if you're behaving like a good net citizen, you probably blocked outbound 25 at the LSN box to begin with so you're not getting any reports because your virus-laden customers aren't able to successfully spam.
Without javascript we'd have an html browser and a Flash browser and when I wanted a newspaper or message board, I wouldn't expose my machine to the risk associated with the Flash browser.
One thing I've been trying to figure out, what exactly is going to happen in the next year or so?
Short answer: NAT.
Lots and lots of perfectly good IP addresses have been deployed in use scenarios which would work perfectly well using RFC 1918 addresses aggregated behind a single public-facing IP address. When you need more IP addresses for a high-value application, you'll raid the places employing them in a low-value application.
It's called a "zero sum game."
Call me crazy, but wasn't DNS invented to remove the significance of using IP addresses as a means of identification?
That was before Javascript security issues mandated dns pinning.
Not that everything (or really much of anything) actually implemented DNS TTLs before, but I like blaming Javascript for all the world's ills.
IANAL, but here's some perspective from someone who has been in the thick of the ARIN policy process for the last few years:
First, you're talking about RIPE (european IP addresses) while the article is about the registration services process at ARIN (north american IP addresses).
Had you been talking about ARIN, this is frankly the kind of thing where you'll want to sign the LRSA and soon. ARIN will work with you to nail down the details and confirm the registration but they'll want to normalize their relationship with you via a signed contract first. I think they'll still update if you come to them with ironclad documentation, but if you had ironclad documentation you'd have been the kind of person who kept the registration up to date to begin with.
For those who are still contactable via at least the email address published on the registration, now is not the time to sign the LRSA. ARIN claims you have more rights under the LRSA than under the regular RSA but on close examination the claim doesn't really hold up. It's a standard adhesion contract in which the powerful party has reserved the rights to themselves.
That having been said, keep tabs on proposed ARIN policy every 6 months or so. ARIN probably won't seek the legal liability from trying to seize legacy registrations that are obviously in use, but the situation could change.
If you are in the situation where your contact details are dead, I personally think you SHOULD sign the LRSA and normalize things with ARIN. A /24 is going to be worth at least $1000 within 12 months, and probably a lot more. IPv6 won't deploy fast enough, the IPv4 free pool will be gone by mid year and the only source of new IPv4 addresses will be folks who are willing to sell.
On the other side, the unrouted dead registrations without valid contacts are very likely to evaporate in the next 24 months. The ARIN policies for this sort of reclamation aren't in place yet, but mark my words: they will be.
Yeah, exactly. I used and liked proftpd back in the day, but why is anyone still using an FTP server for anything? The protocol is not secure or reasonably securable. Come on folks, the writing has only been on the wall for 15 years now...
Make that 30 days if you want network security folk not to laugh at you. 365 if you want any support from law enforcement. Better yet, change your focus to a "do not sell list" where passing a standardized header serves as legal notice that the receiving server is forbidden from sharing any information about the transaction with a third party, specifically or in aggregate. You won't get that either, but at least your only opposition would be from marketing folk.
The network engineers. They'll mess you up man.
Barring plugins with cookie-like features and actual tracking software you've elected to install, it's actually pretty hard to separate out your traffic from everybody else's.
You can keep track of a linear session by passing state in the URL but you lose it as soon as the guy goes somewhere else and comes back. You can do some fuzzy matching based on behavioral patterns but it takes a lot of computing power and the confidence drops off quickly.
Worked in the biz for a little while. The core data came from folks incentivized to knowingly install tracking software on their PCs *and* take surveys because trend data with demographics was much more valuable that trend data without. The data captured from network taps was mostly useful as a tool for correcting the statistical skew in the higher quality data.
Canadian pharmacies looking to sell sudafed?
Right... So as a guy running a web server I'm supposed to "forget" about you probing my server trying to break in because you have the "Don't track me" header set.
We already have such a setting. Tools->Options->Privacy->Uncheck "Accept cookies." Some web sites work with it unchecked. Some don't. Make your choice whether you want their content.
Not exactly. Most ISPs filter their customers announcements that way, but its highly impractical to implement such filters when peering with other ISPs.
The solution boils down to:
1. Temporary filter installed for errant routes
2. Peering POC at source ISP gets a stern lecture and a depeering threat
3. Peering is so valuable (and so costly to lose) that peering POC smacks around the person who allowed the leak in the first place.
4. Mistake repeats because the staff who originally allowed it are incompetent
5. Source ISP gets depeered so he has to pay for all his Internet traffic via a connection that actually is filtered
6. Source ISP fires the fool who screwed up in the first place, cancels the customer contract (if it was customer originated).
7. Source ISP most likely never recovers and ends up being bought out while in or near bankruptcy.
Okay, so steps 4 onward are an artful exaggeration. But seriously, senior network engineers get really bent out of shape when a peer slips them a bum route.
Heck, why is slow-start even still around then?
Now that, my friend, is a VERY good question.
What, are you stupid?
"Document A doesn't say what you claim."
"Yeah, but there's a previous document which does."
"What previous document is that?"
"Hur, learn to use google dude."
Had you just quoted a standards document says "Here's how it's supposed to be done and now we'll offer some suggestions for all of you who decide not to do it this way" I'm not so sure I'd be quick accuse you of being the source of any cognitive dissonance.
Kay, so I've poked through the RFCs a bit...
TCP first defined in RFC 793. No slow start; implementations generally send segments up to the window size negotiated in SYN exchange which is generally the smaller of the speakers' two buffers.
Slow start first referenced in RFC 1122 (Internet host requirements) as: ''Recent work by Jacobson [ACM SIGCOMM-88] on Internet congestion and TCP retransmission stability has produced a transmission algorithm combining "slow start" with "congestion avoidance". A TCP MUST implement this algorithm.''
At this point in the process there does not appear to be an RFC specifying TCP slow start making this statement in a document that is not itself about TCP per se very dubious.
A decade later, RFC 2001 says: "Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery." The word "must" is subsequently used in connection with congestion avoidance but is not used in connection with slow start.
RFC2414 then revisits the question of TCP's initial window size selection referencing RFC 2001 but again declines to state that TCP "must" start with a small window.
RFC 2581 finally sets an unambiguous slow start requirement: The slow start and congestion avoidance algorithms MUST be used by a TCP sender [...] IW, the initial value of cwnd, MUST be less than or equal to 2*SMSS bytes and MUST NOT be more than 2 segments.
However, even as it does so, it goes on to comment that, "We note that a non-standard, experimental TCP extension allows that a TCP MAY use a larger initial window [...] We do NOT allow this change as part of the standard defined by this document. However, we include discussion [...] in the remainder of this document as a guideline for those experimenting with the change, rather than conforming to the present standards for TCP congestion control."
In other words, even though out of the box TCPs MUST implement slow start, it's understood that other behaviors are in use and are expected to continue.
Finally, RFC 3390 allows the out-of-the-box behavior of TCP to use a larger initial window than 2581.
Conclusion: Google still isn't cheating.
Reference please? I'm afraid I'm not up on the sequence of TCP RFCs so I don't know where to find the "previous definition."
IETF uses the capitalized MUST/MUST NOT terminology for a reason. It's used anywhere an implementer could reasonably do something else but for some reason isn't allowed to. Where it isn't present, it isn't required. If the authors omitted that terminology even after referencing RFC 2119 in a standards track modification to such a widely used protocol, they did so because the entire modification is optional.