patcat88
join:2002-04-05
Jamaica, NY
| 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. |
