I suspect home-consumers will get them first, followed by the backbone, followed erratically by ISPs. Datacenters have them now, although sometimes they're turned off!
Hmmn, this is now a bit far from the question of who benefits from net neutrality (;-))
Sort of, but contra-intuitively much of the problem had as its root cause the overly large buffers in routers and the queues that build up in them. The receiver needs to detect the amount of delay in the streaming (not in the path!) and accept at a higher rate until it has enough data in had for the expected delay and some headroom. The sender perhaps can make a guess at this, but I haven't investigated it.
As I noted in the reply above, most of what router (and real-time theatre projector) developers believe is erroneous, and the IETF is in the process of banging on them with a clue-stick. The internet is quite capable of doing things that non-net-techies don't think we can possibly do. Consider, for example satellite links and transatlantic cables: perfectly reasonable people used to think that it was impossible to have a link that long. If my leaky memory serves, Van Jacobsen was involved in fixing that assumption, too (;-))
Our experience some time ago building (Sun) gear for theatre display and provisioning was that the protocols were fine, but there were a lot of botches in the software supposedly implementing them (:-))
The absolute worst was in the software in the projector, but the routers of the day kept getting in our way. Being biased, we preferred to use our own servers for routing, and even there the software wasn't everything we needed. We, and several other people, started off on efforts to do routing differently, some of which now exist (crossbow, software defined networks, etc).
The same observations have returned as of last year: the "bufferbloat" investigation has exposed exactly what you report: router software over-optimized for throughput and avoidance of buffer overflow. In reality good throughput, minimal overflows and minimal delay/jitter comes from paying attention to latency. There's a discussion at http://tools.ietf.org/id/draft... which I helped a little bit with.
As we speak, the bufferbloat community is working on draft RFCs for advanced queue management, the second step towards getting this fixed. There's a meeting scheduled for IETF89, March 2-7, 2014 in London.
In your specific case, your jitter buffer needs to be bigger in seconds than the ^#&$^&*@!! largest queue that builds up in the path between your source and sink, and the software in between needs to get its queue and therefor buffer use down close to one packet (or packet-train). This is measurable, by the way, and described a couple of places in the discussions at https://lists.bufferbloat.net/...
I'll claim that in principle it's easy, and in practice a pain in the ass (:-))
If it weren't being fixed, I'd have exactly the same opinion as you do!
ISPs bottleneck on their respective upstreams, and this makes them a major business (ie, financial) concern. This in turn drives technical decisions to be based on
1. the ability of the delivery arm to express the problem to financial management and
2. to make a business case for any change that has the capability of increasing costs.
The internet is a dumb system of pipes with the intelligence at the edges, specifically so we can do things with it that non-techies don't think we can do.
Streaming video is easier than downloading large programs, as you only need to ship a certain amount per second, rather than ship it all and only be able to use it when the last byte has arrived. For real-time broadcast, which causes massive numbers of synchronized transfers, you can use multicast directely, as well as to "prime" a content delivery network node close to your particular edge.
Press freedom's drop was noticed because of Manning and Snowdon: now American-born reporters are afraid to come home. They've been threatened with both criminal charges and extrajudicial punishment for publishing the leaks. Net result? They get published in the UK.
In your opinion, are these kinds of numbers consistent with what we've seen with other security services? Canada seems to suffer about one full-fledged security fiasco a decade, ranging for burning barns to a naval sub-leftenant spying for Putin's Russia last year. The STASI was reported to be substantially worse.
My suspicions came from civilian experience admistering Trusted Solaris, where the standard sysadmin kludge was to assign both the root and security-administrator roles to the same person, so they could unscrew disfeatures of the security policy in use. The latter tended to be overcomplex, and regularly had my brain bleeding out of my ears (:-)) As in other nominally secure contexts, the sysadmins and DBAs were the weak link, as they were tasked with making the system work, as oppose to keeping it secure.
In Canada at least, the privilege includes protection against publication. See, for example, the Criminal Code, 487.015 (1) (4)(a) where a
a judge may exclude material from a document to be published if it is "privileged or otherwise protected from disclosure by law". Privileged communication, by the way, also include material reported to the police, to a lawyer, and in some circumstances to or by an MP.
Hey guys, if someone defrauds you, you go to the cops. You may want to have a good lawyer beside you, to help reassure them it isn't just you being an asshole, but fraud is one of those breaches of "the king's peace" that police were created to deal with.
In fact, it was a court case, not a legal change in the UK. Besides, I want *all* my money back when the bank loses it for me (;-)) A cap on losses is worthwhile, but only as a backstop to strict liability for an agent's own decisions.
If you're a consultant, you owe your customer a warning if they're being scammed. In the very few cases where I've had to deal with this and had the freedom to demur, I've formally entered a "no bid", with an explanation of the form "upon analysis, the proposed plan will take substantially more time than budgeted, and that failure will reflect on the competence of the consultants involved".
I just wish I'd no-bid on on "teach TDD to a PM", a few years back (;-))
The Vixie article describes doing it at the edge, where one only has one or two uplinks from the local ISP and where the cost is trivial. One wouldn't want to do it closer to the backbone, for the reasons you noted.
It's more of an invalidation check: if a charge goes through with someone else's signature, the bank has to refund my money. In Canada, within 7 days. On a digital pad, the bank has the opportunity to start doing automated checks, which can actually be a verification. Like a lock on a glass door, it doesn't have to be super strong to work (;-))
Could you expand on that a bit? The scenario we were discussing in the other thread had an in-store ATM as the source of the scraping. It yielded my card identification and pin* which were used a few days later at an outside-access bank ATM, along with some large number of other people's. In principle, this should have been nearly impossible as it stood, but since it did happen, I regret to say it was possible (;-))
In particular, how do we get the retailer out of the equation, where in this case the retailer was a somewhat horrified third party hosting an ATM adjacent to the coffee-shop in their store. I suspect he'd have been happy if they'd neverbrought a replacement back!
--dave
[* or its equivalent, sufficient to be able to make a fake deposit and real withdrawl from my account by authenticating correctly as me. It was the number of deposit/withdrawl pairs in a short time that tipped off the bank]
We were in the first 6 months of chip-and-pin, and while the ATMs in question were chip-and-pin, there's nothing saying all the infrastructure was. Banks can be somewhat amoral in their accounting: if preventing theft is more expensive than allowing it, someone will argue for allowing the theft to continue until the beginning of the next budgeting period (;-))
As I noted in another answer, this was on a chip-and-pin card, and multiple skimmed cards were used to make a series of back-to-back withdrawls the following weekend, at a bank branch's outdoor ATM that only allowed chip-and-pin. I suspect good math and buggy code on the card/ATM supplier's part
In Canada, the bank has to make a case that it's your fault, or they have to refund the money within something like 7 business days. As it happens, my bank is very honest, called me on the weekend, got me a new card the same day and refunded the money with only one polite reminder.
In the UK, and in some (most?) States, the same is true. Unfortunately, the banks in some states are distinctly less well-policed, and will drag their feet until you apply force majeure. Were you in Minneapolis, by any chance?
Slashdot Mirror
No, actually: see the continuing discussion below.
The tubes are made of pipes. Bagpipes, if you're in Scotland.
I suspect home-consumers will get them first, followed by the backbone, followed erratically by ISPs. Datacenters have them now, although sometimes they're turned off!
Hmmn, this is now a bit far from the question of who benefits from net neutrality (;-))
Sort of, but contra-intuitively much of the problem had as its root cause the overly large buffers in routers and the queues that build up in them. The receiver needs to detect the amount of delay in the streaming (not in the path!) and accept at a higher rate until it has enough data in had for the expected delay and some headroom. The sender perhaps can make a guess at this, but I haven't investigated it.
As I noted in the reply above, most of what router (and real-time theatre projector) developers believe is erroneous, and the IETF is in the process of banging on them with a clue-stick. The internet is quite capable of doing things that non-net-techies don't think we can possibly do. Consider, for example satellite links and transatlantic cables: perfectly reasonable people used to think that it was impossible to have a link that long. If my leaky memory serves, Van Jacobsen was involved in fixing that assumption, too (;-))
Our experience some time ago building (Sun) gear for theatre display and provisioning was that the protocols were fine, but there were a lot of botches in the software supposedly implementing them (:-))
The absolute worst was in the software in the projector, but the routers of the day kept getting in our way. Being biased, we preferred to use our own servers for routing, and even there the software wasn't everything we needed. We, and several other people, started off on efforts to do routing differently, some of which now exist (crossbow, software defined networks, etc).
The same observations have returned as of last year: the "bufferbloat" investigation has exposed exactly what you report: router software over-optimized for throughput and avoidance of buffer overflow. In reality good throughput, minimal overflows and minimal delay/jitter comes from paying attention to latency. There's a discussion at http://tools.ietf.org/id/draft... which I helped a little bit with. As we speak, the bufferbloat community is working on draft RFCs for advanced queue management, the second step towards getting this fixed. There's a meeting scheduled for IETF89, March 2-7, 2014 in London.
In your specific case, your jitter buffer needs to be bigger in seconds than the ^#&$^&*@!! largest queue that builds up in the path between your source and sink, and the software in between needs to get its queue and therefor buffer use down close to one packet (or packet-train). This is measurable, by the way, and described a couple of places in the discussions at https://lists.bufferbloat.net/...
I'll claim that in principle it's easy, and in practice a pain in the ass (:-))
If it weren't being fixed, I'd have exactly the same opinion as you do!
ISPs bottleneck on their respective upstreams, and this makes them a major business (ie, financial) concern. This in turn drives technical decisions to be based on
The internet is a dumb system of pipes with the intelligence at the edges, specifically so we can do things with it that non-techies don't think we can do.
Streaming video is easier than downloading large programs, as you only need to ship a certain amount per second, rather than ship it all and only be able to use it when the last byte has arrived. For real-time broadcast, which causes massive numbers of synchronized transfers, you can use multicast directely, as well as to "prime" a content delivery network node close to your particular edge.
Press freedom's drop was noticed because of Manning and Snowdon: now American-born reporters are afraid to come home. They've been threatened with both criminal charges and extrajudicial punishment for publishing the leaks. Net result? They get published in the UK.
Thanks for the background!
In your opinion, are these kinds of numbers consistent with what we've seen with other security services? Canada seems to suffer about one full-fledged security fiasco a decade, ranging for burning barns to a naval sub-leftenant spying for Putin's Russia last year. The STASI was reported to be substantially worse.
My suspicions came from civilian experience admistering Trusted Solaris, where the standard sysadmin kludge was to assign both the root and security-administrator roles to the same person, so they could unscrew disfeatures of the security policy in use. The latter tended to be overcomplex, and regularly had my brain bleeding out of my ears (:-)) As in other nominally secure contexts, the sysadmins and DBAs were the weak link, as they were tasked with making the system work, as oppose to keeping it secure.
In an organization as large as the NSA, how many
Mr Snowdon is the tip of the iceberg!
In Canada at least, the privilege includes protection against publication. See, for example, the Criminal Code, 487.015 (1) (4)(a) where a a judge may exclude material from a document to be published if it is "privileged or otherwise protected from disclosure by law". Privileged communication, by the way, also include material reported to the police, to a lawyer, and in some circumstances to or by an MP.
Hey guys, if someone defrauds you, you go to the cops. You may want to have a good lawyer beside you, to help reassure them it isn't just you being an asshole, but fraud is one of those breaches of "the king's peace" that police were created to deal with.
In fact, it was a court case, not a legal change in the UK. Besides, I want *all* my money back when the bank loses it for me (;-)) A cap on losses is worthwhile, but only as a backstop to strict liability for an agent's own decisions.
Bravo!
If you're a consultant, you owe your customer a warning if they're being scammed. In the very few cases where I've had to deal with this and had the freedom to demur, I've formally entered a "no bid", with an explanation of the form "upon analysis, the proposed plan will take substantially more time than budgeted, and that failure will reflect on the competence of the consultants involved".
I just wish I'd no-bid on on "teach TDD to a PM", a few years back (;-))
And the US congress is annoyed because of ICANN's new regional headquarters in Istanbul (;-))
The Vixie article describes doing it at the edge, where one only has one or two uplinks from the local ISP and where the cost is trivial. One wouldn't want to do it closer to the backbone, for the reasons you noted.
It's more of an invalidation check: if a charge goes through with someone else's signature, the bank has to refund my money. In Canada, within 7 days. On a digital pad, the bank has the opportunity to start doing automated checks, which can actually be a verification. Like a lock on a glass door, it doesn't have to be super strong to work (;-))
Could you expand on that a bit? The scenario we were discussing in the other thread had an in-store ATM as the source of the scraping. It yielded my card identification and pin* which were used a few days later at an outside-access bank ATM, along with some large number of other people's. In principle, this should have been nearly impossible as it stood, but since it did happen, I regret to say it was possible (;-))
In particular, how do we get the retailer out of the equation, where in this case the retailer was a somewhat horrified third party hosting an ATM adjacent to the coffee-shop in their store. I suspect he'd have been happy if they'd neverbrought a replacement back!
--dave
[* or its equivalent, sufficient to be able to make a fake deposit and real withdrawl from my account by authenticating correctly as me. It was the number of deposit/withdrawl pairs in a short time that tipped off the bank]
Interesting thought, thanks!
We were in the first 6 months of chip-and-pin, and while the ATMs in question were chip-and-pin, there's nothing saying all the infrastructure was. Banks can be somewhat amoral in their accounting: if preventing theft is more expensive than allowing it, someone will argue for allowing the theft to continue until the beginning of the next budgeting period (;-))
See maevius' comment below: banks may be only half secure...
As I noted in another answer, this was on a chip-and-pin card, and multiple skimmed cards were used to make a series of back-to-back withdrawls the following weekend, at a bank branch's outdoor ATM that only allowed chip-and-pin. I suspect good math and buggy code on the card/ATM supplier's part
Sorry, I was being ambiguous!
Chip and signature-on-a-digital-pad was what I was thinking about, not signature on paper.
In Canada, the bank has to make a case that it's your fault, or they have to refund the money within something like 7 business days. As it happens, my bank is very honest, called me on the weekend, got me a new card the same day and refunded the money with only one polite reminder.
In the UK, and in some (most?) States, the same is true. Unfortunately, the banks in some states are distinctly less well-policed, and will drag their feet until you apply force majeure. Were you in Minneapolis, by any chance?