If you've created an "open invitation" for them to come into your house (ie, unattended automatic updates) whenever they want, that's your own look-out.
Unless they wish to claim that "0x0403" is entitled for trademark protection, the driver is hardly in a position to distinguish between the two.
They could make an argument that "0x0403" is a reference to the "FTDI" identifier, which is trademarked, and so they are claiming (to hardware and anyone who talks to it directly) that they *are* made by the vendor 0x0403/FTDI. At which point, it's a textbook trademark dilution matter.
*My* company doesn't go under in that model, because my company in that model is more careful about where I buy my chips from, getting them directly from FTDI for example, to ensure the provenance of the hardware I'm selling, rather than trying to find lots of them on alibaba.
When you explain to accounting that we lose ALL the money if they use the fake chips, versus a small amount of money by using the real, most accountants get it.
And - yes - there are companies who will randomly sample chips from lots of 1000, 10,000, whatever, and open them up to verify that "the five units we sampled in this lot at random" were legitimate. It's part of their COGS calculations.
You invited the agent of Rolex/FTDI into your house by presenting your counterfeit chip to its driver, in this analogy.
Also, FTDI destroyed *everything* that was fake, not just the winding gear. So for the analogy to be accurate, they'd have to destroy the entire watch (which is actually what they do today).
If users are allowing code to operate on their systems to alter firmware, etc., without their explicit authorization, that's a conversation between them and their OS vendor as to how that should work.
When you send your fake Rolex (that you think is real) into Rolex for service, they don't send it back to you, they confiscate it as a counterfeit and it's destroyed. I went through this myself with a fake Mophie battery pack. They sent me back a photograph of the giant piles of counterfeit batteries that they confiscate because they came in for warranty work, and they weren't real.
If I was a hardware manufacturer, this would make me MORE likely to use FTDI chips. It means I have greater confidence that what I'm getting is "real", because I know that they are actively trying to make counterfeiting their product more difficult.
If you have more than 1 programmer you have a need for distributed version control.
Bull. Shit.
Programming teams -- LARGE programming teams -- got along just fine without distributed version control for LITERALLY decades. I am on the fence about its usefulness in pure programming applications (like, as someone else mentioned, the kernel), but am absolutely opposed to its use for things like your configuration-management repository, the repo you store your DNS zonefiles in, etc., etc.
I would suggest to you that if you think the only thing people are using version control for is "source code", then you don't understand the enterprise.
There are many usecases where people will need a centralized version control system (VCS). SVN was written ground up to be best in class centralized VCS and they accomplished this goal while building a very elegant and efficient client server framework to boot.
this, this, a thousand times this.
I wish I'd seen your comment before I posted my own similar comment.
I wish people would stop pretending that the DSCM model is the "only way of the future". There are plenty of completely valid use-cases for monolithic source control models. For instance, I am a firm believer that configuration management repos belong in a strictly monolithic architecture, with a single source of truth, deterministic version numbering, etc., etc....
Certainly I could see a case for moving people from CVS to something more modern (but in the same basic vein) like SVN, but here's the thing:
If their existing SCM application is working for them, and they're happy with it, then it's perfectly fine.
I'm afraid that possibility has been discounted. Netflix has paid up. Didn't you get the memo?
Just because Netflix paid to improve the bandwidth cap on their peering point doesn't mean that the assertion ("my traffic is being throttled because it looks like netflix") was accurate.
Nope, it isn't safe to assume that. If that was the case then this traffic would be blocked completely, but it isn't, and what's more it is being modified. Do read the article.
I did read the article, which is how I was able to point out the numerous flaws in it.
It's really quite simple. If you have a download speed topping out far lower than your maximum and you then connect through a VPN and get more available bandwidth then there is a rabbit away somewhere. Netflix have already now paid up anyway to get rid of this 'issue' for their users, so that debunks this bit of dog shit.
It means you've routed out your ISP through a peering point that isn't Level3, and that the peering point between your VPN provider and L3 is less saturated than your ISPs. That's all it proves.
Connecting to something on port 25 and allowing inbound connections to something you have running on port 25 are two entirely different things. If you don't know that then you really don't know anything at all and frankly aren't qualified to comment.
Connections to port 25 have been set aside for "server to server" (e.g., MTA) communications for quite some time now, with "client to server" (e.g., MUA) communications moved to tcp/587 for over a decade. Thus, if you are connecting to tcp/25, it is safe to assume, in this day and age, that you *are* an MTA. If you were an MUA, you'd be using tcp/587.
If you don't know that, then you really don't know anything at all and frankly aren't qualified to comment.
When the original article cites as its first example of network tinkering the already thoroughly debunked "faster Netflix through my VPN" video, the level of technical credibility to the article is already set at "abysmal". There's no argument that the VPN tunnel was faster (obviously), but the alleged reason (which many sites, including this fine establishment, got on the bandwagon for, even though they should know better) was horseshit.
Second, the article demonstrates the problem with a connection to tcp/25. Unless the customer is running a mail *server* on their residential ISP line, they should be connecting to tcp/587. The wireless provider in question here is absolutely within their bounds to say "they don't want you running an SMTP MTA on the wifi", but that running a normal MUA is fine. Is there any evidence that this problem also exists for connections to tcp/587?
The pipe was more than big enough, but ISPs chose to not allow all the packets through.
You might not be aware of this, but that happens with peering, data-centers, etc., all the time. Where the physical layer is capable of, say, Gigabit throughput, but you're only paying for 10Mbps (and they're only reserving for you throughput through their infrastructure of 10Mbps). You pay for the larger "pipe" (e.g., a higher cap), and voila, the valve on the pipe is opened wider.
That's exactly what happens in this Comcast/Level3 situation.
If you've got fiber installed, and switch port connections available, lighting up the fiber costs pennies per terabit transferred,
You are looking more and more like someone who doesn't understand the fundamental cost-centers of large scale network administration with every post.
Your insistence that internet service is the equivalent to telegraph and telephone service only shows that you don't really understand the underpinnings of internet service.
No, I get that. I just don't see the backbone providers changing. Nobody is going to want to be the one who makes such a massive change that impacts billions of dollars of revenue (in connected customers) and the "trailblazer" in finding the pitfalls that need addressing along the way. This is an area where jumping out to the bleeding edge is rarely, if ever, rewarded, and where there is precious little ability to adequately test lab environments under anything approaching "real world" conditions.
It's an idea that might've taken hold if the Internet was being deployed from the ground up today, but I don't see it being implemented in the current environment.
Perhaps that's me being a 20 year industry-vet curmudgeon at this point. Not sure.:-)
I've addressed this fallacy elsewhere: the parts of tax subsidies which had actual contractual, regulatory, or statutory "requirements" tied to them have been either upheld, or worked out through the existing oversight processes. What you're asking for is something new which (frankly) nobody thought to include in the requirements when such things were being done decades ago. That's not the ISPs' fault, it's "ours" collectively for having something of buyer's remorse about the deal we negotiated with them.
But pretending that we're Darth Vader, telling them we've altered the deal and to pray we don't alter it any further is not governance, but tyranny.
What you're describing has not really been done "at scale" (in my experience and understanding anyway) by anything other than a few companies. Expecting that the backbone providers are all going to change their traffic infrastructure to accommodate this model you describe may not really be practical for "the current Internet".
For something like an "Internet2" type of green-field deployment, if we "had it all to do over again, starting with the tech of today", you might be onto something. But I don't see that change happening in today's environment.
Oh, I remember dial-up ISPs all too well. I helped build two of them, and then was there for the lighting up of one of the first/few MMDS (wireless cable) ISPs. As you point out: I've got a low ID#, I've been to this dog and pony show for a long long time.:-)
As I said elsewhere in this sub-thread, I'm fine with any of a number of ways of introducing competition:
competitive wholesale access
electric companies acting as the disinterested neutral third-party fiber carrier for competition
communities deciding to install fiber for community-networks (provided they also allow for competitors to access that fiber
But attacking the problem from the "neutrality" side of the argument is just a misguided tactic, putting another piece of duct-tape on an already shoddy arrangement. There's plenty of ways to crack that nut.
And that should be mandated on the cable side of the wall as well. The reason it gets no traction on the telco side of the playing field is that they aren't really investing in outside-plant upgrades (FIOS was a dismal money-losing failure for Verizon, which is why you haven't seen a new community be rolled out in years, except in one case where a court ordered them to because they'd contractually agreed to roll it out but hadn't done so after halting rollouts).
Cable on the other hand has a constantly growing need for capacity (for video) and so has been doing plant-upgrade after plant-upgrade over the intervening time.
You're making the classic mistake of thinking that the "transit data-rates" is the dominant cost factor. It's not... switching and routing equipment, for the types of throughput you're describing, is where the real costs lie. I think your assertions about hardware costs are extremely low-ball, and this comes from someone who's been in charge of spec'ing, approving and buying network hardware for the last ten-plus years of his career.
Your minimal-government-intervention solution is for the government to force the incumbent ISPs to lease their privately-owned infrastructure to their competitors, and at government-regulated prices? I am interested to see how you justify that as a lower regulatory burden than forbidding the prioritization of packets based on origin.
Sure, it's simple.
The solution you propose is a long-term regulation which needs to exist forever in order to solve the problem.
The solution I propose is a medium-term regulation which only needs to exist for a decade or two until the previously-government-squashed competition is given sufficient opportunity to re-assert itself in the marketplace.
That makes it a less intrusive burden, as it is not permanent, and doesn't actually cost the carrier money (because they still are recouping the cost of the service they're providing to the competitors).
I understand your assertion, and simply disagree with it profusely.
There was no "understanding" associated with the tax-relief. If there was, it'd be codified in the laws and regulations surrounding such tax relief. If there had been such codification, this wouldn't even be a discussion, it'd be "no, your statutorily prohibited from doing that," or "OK, that's fine, but to do it, you need to repay the $nnn,nnn,nnn,nnn.00 in tax relief that was predicated on not doing so." Instead, folks like yourself - who actually don't understand the issue at all, get all hand-wavy about "we gave them tax relief" and assume that there was some actual agreements codified around it, which weren't actually there.
Let me be clear on something: you haven't paid for "a packet". You've paid for a pipe, capable of a given flow-rate. In this case, Netflix (for example) has also paid for "a pipe", capable of a given flow rate, into the system you get your data from. It's not nearly big enough, though, to service all the people who want to consume data from Netflix. Now, your argument is that the people who sell the pipes should just give Netflix a bigger pipe and take it on the chin because goddamnit you want to watch your Breaking Bad reruns. But the pipe Netflix needs, to do what you're asking, is really goddamned big. Big enough that if Netflix wants a pipe that big, it should damned well pay for upgrading it themselves. That includes both just the physical pipe, but also whatever the people who sell the pipes need to charge in order to able to handle the inflow of data from a pipe that big, sending it on to all the various places where those bits are going to drop back out into your laptop.
Your attempt to fixate on "charging for packets" is laudable. It certainly makes for a more compelling argument, or it would if there were any companies charging "by the packet" instead of "by the width of the pipe."
By all means, though, if you want to go to "paying by the packet" billing, I suspect the telcos and cable companies would be happy to oblige. It's a much more tenable business model for everyone involved, charging metered service, so that those who put the most actual strain on the network pay the most. But the last time a carrier tried that (TWC, 2008, in field trials in Texas) there was a hue and cry from folks - on this very site - against such "paying by the packet".
So, believe me, I very much understand the issue, and have been paying attention to it before you had even heard the phrase "net neutrality."
Except that electrical utilities haven't already brought sufficient fiber into residential neighborhoods. They're not bringing out NEARLY the amount of fiber to the pole you'd need to in order to sufficiently handle "broadband everywhere".
Realistically, I'm fine with any of the various options for "how to get competition in the marketplace". But I think that is the answer rather than trying to interfere with day to day traffic management policies.
Slashdot Mirror
If you've created an "open invitation" for them to come into your house (ie, unattended automatic updates) whenever they want, that's your own look-out.
They could make an argument that "0x0403" is a reference to the "FTDI" identifier, which is trademarked, and so they are claiming (to hardware and anyone who talks to it directly) that they *are* made by the vendor 0x0403/FTDI. At which point, it's a textbook trademark dilution matter.
As I said in the other reply: buy direct. They sell direct. No need for a middle man.
And if they brick the chips I purchased from them, I have a legitimate cause of action against them for the damages they caused by it.
No problem either way.
*My* company doesn't go under in that model, because my company in that model is more careful about where I buy my chips from, getting them directly from FTDI for example, to ensure the provenance of the hardware I'm selling, rather than trying to find lots of them on alibaba.
When you explain to accounting that we lose ALL the money if they use the fake chips, versus a small amount of money by using the real, most accountants get it.
And - yes - there are companies who will randomly sample chips from lots of 1000, 10,000, whatever, and open them up to verify that "the five units we sampled in this lot at random" were legitimate. It's part of their COGS calculations.
You invited the agent of Rolex/FTDI into your house by presenting your counterfeit chip to its driver, in this analogy.
Also, FTDI destroyed *everything* that was fake, not just the winding gear. So for the analogy to be accurate, they'd have to destroy the entire watch (which is actually what they do today).
If users are allowing code to operate on their systems to alter firmware, etc., without their explicit authorization, that's a conversation between them and their OS vendor as to how that should work.
When you send your fake Rolex (that you think is real) into Rolex for service, they don't send it back to you, they confiscate it as a counterfeit and it's destroyed. I went through this myself with a fake Mophie battery pack. They sent me back a photograph of the giant piles of counterfeit batteries that they confiscate because they came in for warranty work, and they weren't real.
This is functionally no different from that.
If I was a hardware manufacturer, this would make me MORE likely to use FTDI chips. It means I have greater confidence that what I'm getting is "real", because I know that they are actively trying to make counterfeiting their product more difficult.
Bull. Shit.
Programming teams -- LARGE programming teams -- got along just fine without distributed version control for LITERALLY decades. I am on the fence about its usefulness in pure programming applications (like, as someone else mentioned, the kernel), but am absolutely opposed to its use for things like your configuration-management repository, the repo you store your DNS zonefiles in, etc., etc.
I would suggest to you that if you think the only thing people are using version control for is "source code", then you don't understand the enterprise.
this, this, a thousand times this.
I wish I'd seen your comment before I posted my own similar comment.
I wish people would stop pretending that the DSCM model is the "only way of the future". There are plenty of completely valid use-cases for monolithic source control models. For instance, I am a firm believer that configuration management repos belong in a strictly monolithic architecture, with a single source of truth, deterministic version numbering, etc., etc....
Certainly I could see a case for moving people from CVS to something more modern (but in the same basic vein) like SVN, but here's the thing:
If their existing SCM application is working for them, and they're happy with it, then it's perfectly fine.
Just because Netflix paid to improve the bandwidth cap on their peering point doesn't mean that the assertion ("my traffic is being throttled because it looks like netflix") was accurate.
I did read the article, which is how I was able to point out the numerous flaws in it.
Thanks for playing, though.
It means you've routed out your ISP through a peering point that isn't Level3, and that the peering point between your VPN provider and L3 is less saturated than your ISPs. That's all it proves.
Connections to port 25 have been set aside for "server to server" (e.g., MTA) communications for quite some time now, with "client to server" (e.g., MUA) communications moved to tcp/587 for over a decade. Thus, if you are connecting to tcp/25, it is safe to assume, in this day and age, that you *are* an MTA. If you were an MUA, you'd be using tcp/587.
If you don't know that, then you really don't know anything at all and frankly aren't qualified to comment.
When the original article cites as its first example of network tinkering the already thoroughly debunked "faster Netflix through my VPN" video, the level of technical credibility to the article is already set at "abysmal". There's no argument that the VPN tunnel was faster (obviously), but the alleged reason (which many sites, including this fine establishment, got on the bandwagon for, even though they should know better) was horseshit.
Second, the article demonstrates the problem with a connection to tcp/25. Unless the customer is running a mail *server* on their residential ISP line, they should be connecting to tcp/587. The wireless provider in question here is absolutely within their bounds to say "they don't want you running an SMTP MTA on the wifi", but that running a normal MUA is fine. Is there any evidence that this problem also exists for connections to tcp/587?
You might not be aware of this, but that happens with peering, data-centers, etc., all the time. Where the physical layer is capable of, say, Gigabit throughput, but you're only paying for 10Mbps (and they're only reserving for you throughput through their infrastructure of 10Mbps). You pay for the larger "pipe" (e.g., a higher cap), and voila, the valve on the pipe is opened wider.
That's exactly what happens in this Comcast/Level3 situation.
You are looking more and more like someone who doesn't understand the fundamental cost-centers of large scale network administration with every post.
Your insistence that internet service is the equivalent to telegraph and telephone service only shows that you don't really understand the underpinnings of internet service.
No, I get that. I just don't see the backbone providers changing. Nobody is going to want to be the one who makes such a massive change that impacts billions of dollars of revenue (in connected customers) and the "trailblazer" in finding the pitfalls that need addressing along the way. This is an area where jumping out to the bleeding edge is rarely, if ever, rewarded, and where there is precious little ability to adequately test lab environments under anything approaching "real world" conditions.
It's an idea that might've taken hold if the Internet was being deployed from the ground up today, but I don't see it being implemented in the current environment.
Perhaps that's me being a 20 year industry-vet curmudgeon at this point. Not sure. :-)
You invested? like with a prospectus and such?
I've addressed this fallacy elsewhere: the parts of tax subsidies which had actual contractual, regulatory, or statutory "requirements" tied to them have been either upheld, or worked out through the existing oversight processes. What you're asking for is something new which (frankly) nobody thought to include in the requirements when such things were being done decades ago. That's not the ISPs' fault, it's "ours" collectively for having something of buyer's remorse about the deal we negotiated with them.
But pretending that we're Darth Vader, telling them we've altered the deal and to pray we don't alter it any further is not governance, but tyranny.
What you're describing has not really been done "at scale" (in my experience and understanding anyway) by anything other than a few companies. Expecting that the backbone providers are all going to change their traffic infrastructure to accommodate this model you describe may not really be practical for "the current Internet".
For something like an "Internet2" type of green-field deployment, if we "had it all to do over again, starting with the tech of today", you might be onto something. But I don't see that change happening in today's environment.
Oh, I remember dial-up ISPs all too well. I helped build two of them, and then was there for the lighting up of one of the first/few MMDS (wireless cable) ISPs. As you point out: I've got a low ID#, I've been to this dog and pony show for a long long time. :-)
As I said elsewhere in this sub-thread, I'm fine with any of a number of ways of introducing competition:
But attacking the problem from the "neutrality" side of the argument is just a misguided tactic, putting another piece of duct-tape on an already shoddy arrangement.
There's plenty of ways to crack that nut.
And that should be mandated on the cable side of the wall as well. The reason it gets no traction on the telco side of the playing field is that they aren't really investing in outside-plant upgrades (FIOS was a dismal money-losing failure for Verizon, which is why you haven't seen a new community be rolled out in years, except in one case where a court ordered them to because they'd contractually agreed to roll it out but hadn't done so after halting rollouts).
Cable on the other hand has a constantly growing need for capacity (for video) and so has been doing plant-upgrade after plant-upgrade over the intervening time.
You're making the classic mistake of thinking that the "transit data-rates" is the dominant cost factor. It's not ... switching and routing equipment, for the types of throughput you're describing, is where the real costs lie. I think your assertions about hardware costs are extremely low-ball, and this comes from someone who's been in charge of spec'ing, approving and buying network hardware for the last ten-plus years of his career.
*grr* How can it be 2014 and /. still doesn't let you edit your own post? My "your/you're" gaffe is going to bother me for weeks.
Sure, it's simple.
The solution you propose is a long-term regulation which needs to exist forever in order to solve the problem.
The solution I propose is a medium-term regulation which only needs to exist for a decade or two until the previously-government-squashed competition is given sufficient opportunity to re-assert itself in the marketplace.
That makes it a less intrusive burden, as it is not permanent, and doesn't actually cost the carrier money (because they still are recouping the cost of the service they're providing to the competitors).
I understand your assertion, and simply disagree with it profusely.
There was no "understanding" associated with the tax-relief. If there was, it'd be codified in the laws and regulations surrounding such tax relief. If there had been such codification, this wouldn't even be a discussion, it'd be "no, your statutorily prohibited from doing that," or "OK, that's fine, but to do it, you need to repay the $nnn,nnn,nnn,nnn.00 in tax relief that was predicated on not doing so." Instead, folks like yourself - who actually don't understand the issue at all, get all hand-wavy about "we gave them tax relief" and assume that there was some actual agreements codified around it, which weren't actually there.
Let me be clear on something: you haven't paid for "a packet". You've paid for a pipe, capable of a given flow-rate. In this case, Netflix (for example) has also paid for "a pipe", capable of a given flow rate, into the system you get your data from. It's not nearly big enough, though, to service all the people who want to consume data from Netflix. Now, your argument is that the people who sell the pipes should just give Netflix a bigger pipe and take it on the chin because goddamnit you want to watch your Breaking Bad reruns. But the pipe Netflix needs, to do what you're asking, is really goddamned big. Big enough that if Netflix wants a pipe that big, it should damned well pay for upgrading it themselves. That includes both just the physical pipe, but also whatever the people who sell the pipes need to charge in order to able to handle the inflow of data from a pipe that big, sending it on to all the various places where those bits are going to drop back out into your laptop.
Your attempt to fixate on "charging for packets" is laudable. It certainly makes for a more compelling argument, or it would if there were any companies charging "by the packet" instead of "by the width of the pipe."
By all means, though, if you want to go to "paying by the packet" billing, I suspect the telcos and cable companies would be happy to oblige. It's a much more tenable business model for everyone involved, charging metered service, so that those who put the most actual strain on the network pay the most. But the last time a carrier tried that (TWC, 2008, in field trials in Texas) there was a hue and cry from folks - on this very site - against such "paying by the packet".
So, believe me, I very much understand the issue, and have been paying attention to it before you had even heard the phrase "net neutrality."
Except that electrical utilities haven't already brought sufficient fiber into residential neighborhoods. They're not bringing out NEARLY the amount of fiber to the pole you'd need to in order to sufficiently handle "broadband everywhere".
Realistically, I'm fine with any of the various options for "how to get competition in the marketplace". But I think that is the answer rather than trying to interfere with day to day traffic management policies.