BitTorrent Trend Suggests ISPs Need to Improve Networks > The Way the Internet Should Be

reply to TheMG

Re: The Way the Internet Should Be

You are missing the point... You read the words, but you decide what meaning come out of them.

My point would be, using your TV, or the internet, shouldn't lead one to feel as though they are somehow abusing the system, because they enjoy it one way or another.

Just because the systems don't work the same, to the end user, they are no different, and frankly, no one should have to worry about how much, or how little they use them.

After all, both systems are more or less sold in the same manner, TV could just as easily have small text some place, telling you not to watch more than X hours a week, just like some internet service providers hide usage limits in small text.

Sooner or later, the average users will catch up with the heavy users, in what they expect for their dollars.
--
Give me bandwidth or give me death!
»/testhistory/661871/4f240

reply to TheMG
Yes, the internet IS different. Didn't you read the article about the increased SPEEDS they keep offering. The solution, however, is VERY SIMPLE. Don't SELL what you can't provide. If they are only CAPABLE of serving 1Mb/sec, then SELL 1mb/sec. If 100% of their users are using 1Mb/sec, and they have the ability to PROVIDE 1Mb/sec, then there is no problem. However, if they SELL 10mb/sec, and they can only PROVIDE 1mb/sec, then, of course, EVERYONE is unhappy.
--
The happiest countries are the most secular. The struggle AGAINST corporations is the struggle FOR humanity!

reply to TheMG

reply to gatorkram
I got your point, gatorkram. We should view them both as an appliance, to be turned on and used at will. They are just "there" to be used - not to worry about how much we are using them, or what we are using them for. The only concern should be ease of use and ready access - not content monitoring, throttling, or whatever.

Expand the networks to meet the need, instead of trying regulate usage to save capital expenditure. Those companies who can't or won't should be subsumed by those who have the foresight to see what future needs will be. Computer usage should be ubiquitous, not worrisome.
--
Life is simply one damned thing after another.

reply to gatorkram
You are abusing TV the more you watch it. The more TV you watch, the less each ad impression is valued. We need to goto congress and demand laws to stop the ransacking and piracy of the value of ad impressions.

reply to RARPSL
Multicast would solve all ALOT of P2P traffic. Problem is, the IANA has turned Multicast into a impossibly expensive to reach system, and its unscalable, since it has a concept of "groups" which have to be registered on all the routers on the internet, and then torn down, eating router performance like crazy. Also you need a special IP to "send" your packets to, that special IP represents all the IPs that want to receive your packet. Next almost all domestic ISP's routers can not see multicast and don't forward them.

Solution, although its not pretty, is »tools.ietf.org/html/rfc5058 Explicit Multicast, where the destination of the packet are in the packet. Zero state information needed by routers, they just send the packet out on 2/3/4/etc different ports when they see it. Then there is the 1500 byte packet limit. If the routers don't strip "unneeded" IPs from the packet, the last mile will be less efficient (the packet you get contains many other IPs), but through the internet core it would be much more efficient, since the data only travels only once through any router anywhere. There is a point where a group makes sense because of the insane overhead if you stuff a packet entirly with destination IPs and and only a couple bytes of data. For example, I cooked up this formula that says how many MB someone will have to download
((([file size]/(1500-16-(4*[IPs that receive this packet])))-([file size]/(1500-20)))*1500)/(1024*1024)

A UDP+IP4 header is 20bytes (includes 1 destination IP), for Explicit Multicast, I assume each additional IP eats up 4 bytes of 1500 of each packet (the world runs off ethernet doesn't it?), im ignoring any bytes/bits for number # of IPs included in the header, but 2 bytes is all you need to give you an unrealistic 65000 IPs in the header.

Also I'm ignoring any header gains through IP header compression, but I don't feel like reading how that works, and thats best case scenario.

But with our formula, with a 700MB CD, and 10 users, each user will get a low 16 MB of overhead. (blame google calc for spaces)
(((700 000 000 / (1 500 - 16 - (4 * 10))) - (700 000 000 / (1 500 - 20))) * 1 500) / (1 024 * 1 024) = 16.8679761

but with 190 users we will double our overhead (706MB overhead), actually, have more overhead than file.
(((700 000 000 / (1 500 - 16 - (4 * 190))) - (700 000 000 / (1 500 - 20))) * 1 500) / (1 024 * 1 024) = 706.49794

and at the extreme maximum of 371 destination IPs, we have a jaw dropping 249 GB of overhead
(((700 000 000 / (1 500 - 16 - (4 * 370))) - (700 000 000 / (1 500 - 20))) * 1 500) / (1 024 * 1 024) = 249 662.915

Remember, for a uploader, this will take a month/months to upload this even though in theory you are saving SOME bandwidth.
700 * 371 = 259,700MB conventional way
700 MB to 371 users through Explicit Multicast= 250,239MB

((700 000 000 / (1 500 - 16 - (4 * 370))) * 1 500) / (1 024 * 1 024) = 250 339.508

Im not particularly a math wizz, plus I don't have my wonderful TI-89 on me right now. Now at such a high (370) destination IPs, it becomes nearly useless to do explicit multicasting, with traditional group multicasting we wouldn't have any of these problems, since you only need to send to "1" IP, and the internet will magically route it to everyone "behind" that 1 IP. But the current internet's multicasting is broke and unusable by masses. The insane overhead might be more practical with smaller groups, since there will have to be somewhere a cutoff between putting destination IPs in the headers and doing group multicasting. 190 destination IPS doesn't look bad.

((700 000 000 / (1 500 - 16 - (4 * 190))) * 1 500) / (1 024 * 1 024) = 1 383.0912 MB

1400MB to send 700MB to 190 people. Not bad at all when unicasting it would be 133000MB (190*700).

Also there would have to still be a TCP channel/traditional p2p to clean up/patch up after all the lost packets, so this would just make bittorrent extremely fast, since a 1 uploader can feed 200 users from only 2x more upload. Another problem would be, if the uploader is uploading faster than the peers can download the multicast stream, meaning alot of packets would be missing, to whatever % your download is slower than the uploader's upload speed. But then again, most broadband connections are asymmetrical, so there wouldn't be a problem usually. Even then, other peers can look at their view of the swarm, and the rarest pieces can be multicasted up, and then the peers play patching duty (TCP unicast chunk transfers).

Also jumbo ethernet frames might help since we wont be limited to 1500 byte packets. But, as I type this I realise, any network core changes, such as group multicast, and explicit multicast, and Jumbo Frames, chance of those ever being repaired, ZERO. You can hope for something better in IP6, since that will be a generational upgrade, but think of all the routers and IP equipment there already, upgrading will be impossible, period.

In the end, for bittorent, multicasting would decrease traffic, but it can't fix all the problems, ISP caching would be much easier to implement, or just have mega ISP servers act as peers, and firehouse each torrent with uploading, so no peer ever needs to upload again, but then again, what about the downloading strain?

So yeah, the only solution is, upgrade or die. And die is what American ISPs decided (except for Verizon). Throttle, cap, terminate, never upgrade.