Slashdot Mirror
Bell's Own Data Exposes P2P As a Red Herring
dougplanet writes with news from the Canadian-throttling front: "As ordered by the CRTC, Bell has released (some) of its data on how torrents and P2P in general are affecting its network. Even though there's not much data to go on, it's pretty clear that P2P isn't the crushing concern. Over the two-month period prior to their throttling, they had congestion on a whopping 2.6 and 5.2 per cent of their network links. They don't even explain whether this is a range of sustained congestion, or peaks amongst valleys."
It was so obvious, we know ISP's are the worst kinds of businesses, they oversell the bandwidth massively on the customer end and yet their backbones are pretty hardly ever used so they just end up cheating the consumer. It's basically extortion.
The blog linked to is pure shit. Here's a link to the actual article:
http://www.cbc.ca/technology/story/2008/06/25/tech-caip.html
In revealing the details, Bell explained in an accompanying letter that "while these numbers may seem low to the average lay person, they are significant to network traffic engineers such that it is important to consider the number of congested links in the proper context." - of-course, the context being that Bell would like to make more money from various throttling schemes as well as from their new IPTV stores.
If only a single link in the network is congested, end users may still experience slowdowns or dropped connections, the company said, - of-course, especially if you throttle these connections.
because the situation is similar to the road system -- where if one major artery is backed up, all connected roads will also have problems. - of-course they conveniently omit the fact that the Internet is designed to route around damaged/congested areas.
You can't handle the truth.
Delays occur whenever anything is waiting in an output queue instead of being immediately transmitted. This could happen at very low average utilization levels if multiple sources all try to send data across a link simultaneously. The delay time is a function of the number of bytes waiting to be transmitted and the transmit speed.
Retransmission delays occur when the output queue gets full, the router drops additional packets as they come in, and the TCP connection hangs until the retried packets come through (700ms for the first one, much more for subsequent dropped packets). To avoid compounding the problem, output queues on routers are typically sized to something a fair bit less than 700ms.
The bank needs to repay you the money they let Bell steal.
If a bank allows money to be withdrawn from an account of a deceased person, then the bank is liable to put the money back WITH interest and penal charges.
Once a person dies, the bank needs to legally freeze the account to prevent any deposits or withdrawals (esp. withdrawals).
Only the estate or the nominee can withdraw (not deposit) ALL the money from the account in one single operation.
Nope, the bank cannot unilaterally close and send you a check for the same. If you are the legal heir, you need to either prove by way of nomination OR successor OR court orders asking the bank to pay you the money.
The check that the bank cashed and the Direct Debit, if both happened AFTER your dad died, are not valid. In a court you WILL prevail, plus the bank has to pay a nasty fine.
But BEll cannot be held liable. You were not in a contractual relationship with Bell.
Order the bank in writing stating facts and giving them 7 days to repay you with interest.
If the bank fails to respond, file a criminal case stating fraud, and simulatenously ask the court to rule in your favor citing your dad's death certificate and date of debit.
The court usually will not want to hear from the bank because if the debit happened AFTER death then any legal arguments are moot.
Get a court order making the bank pay you.
If you want to play real nasty, send the order by ordinary post undistinguishable from other letters (after all banks hide their rate increases in same way) to the bank's registered office (NOT the branch). Those morons at the registered office will have no clue and throw away the letter. (Assuming you have given a deadline to pay you from date of letter do next steps).
Approach the court again whining pitifuly (yes it pays) that the Holy Judge's order was disobeyed (get the same judge) by an unruly bank.
The judge will ask what you want to do next.
This is most important: Now the culpability of the bank is established as defying court orders (your money now plays a second role. Judges don't like to see anyone defying their orders). Request the court grants you permission to seize and auction the bank's nearest branch's assets to get your money back. The judge will accept this.
Go with a sheriff and his posse to the branch, and now you are legally authorised to rob the bank. You can shut down the doors, throw out customers, restrain staff, seize cash from tills, auction PCs on the spot (better yet, arrange a few friends to be there for the auction to get bank's PCs at HUGE discounts). Sell ALL their stuff to get your money back: Remember, your goal is to first bankrupt the branch. Don't seize cash. Seize the hardware, valuable furniture anything that the bank needs to run its branch. Sell it on doorfront with sheriff standing by for a dollar or whatever you like.
The bank will try to move mountains to get the order overturned. So do it quickly, very fast. Get some 100 friends to suddenly appear, bid for the assets, and block the traffic to prevent their lawyers from reaching you to serve you a STOP SALE order they can get from a sympathetic judge.
Good luck
"Doing what i can, with what i have." ~ Burt Gummer
Kristof Obermann, he used to work at Arcor one of the bigger ISPs and phone companies in germany. He now works as a professor.
Besides, it's not like twice as much bandwidth costs twice as much money. Besides there's always redundancy. So in case one line breaks, you'll be at 100% peak utilisation. And then you will have problems as you will loose packets.
If those situations would exist, ISPs would use the TOS fields. Packets belonging would just be dropped more likely in case of a network overload. Nobody notices a missing packet at a download as the server will continue sending packets and the missing one eventually gets retransmitted a few seconds later. Missing packets are a _lot_ more noticable at web-browsing or interactive sessions.
You're completely incorrect because you're completely ignoring Bell's criteria for a line being considered congested.
First, their thresholds: They consider anything over the following utilization thresholds to be congested:
DS-3 61%, OC-3 84%, OC-12 and OC-48 90%.
Second, they determine usage and congestion by taking samples every 15 minutes. If five samples return percentages over those limits in a 14 day period, the line is considered to be congested for the entire 14 day period.
Their percentages are actually not all that bad; they're a useful guideline for when it's time to turn on another link. Their methodology for MEASURING the usage, on the other hand, is completely flawed. A two-hour long DDoS attack one afternoon might mark a slew of lines as congested for two entire weeks.
Further bolstering the fact that they've chosen their measurements to make the issue seem worse than it appears is that despite the supposed congestion on a given percentage of their lines, they only have about 4000 ATM cell loss events network-wide each month. This is out of the trillions of ATM cells flying around their network every month, they only drop a percentage so small that my calculator resorts to scientific notation trying to calculate it.
In short, they've pretty much made up the issue. Their figures when taken at face value don't indicate significant congestion (5% of lines congested? Why not just purchased a handful more lines?), when examined based on their methodology appear to be garbage data, and when compared against actual packetloss caused by congestion, is proven to be completely non-existent. Bell has zero actual network congestion, their own ATM loss data backs that up.
Disclaimer: I'm not a network engineer, and so I might be talking out of my ass. But I think that common sense can play a role here; their methodology makes it trivial to declare a line as congested, and having 4000 instances of ATM cell loss on a network in a month with millions of customers (and trillions of ATM cells sent per month) doesn't seem particularly bad.