how-to block ads
|
|
Uniqs:
334 |
Share Topic
 |
 |
|
|
| Let's not leave out the criticisms in Bennet's rewrite »www.theregister.co.uk/2008/12/05···ent_udp/One thing that is certain is that uTP will not reduce the volume of traffic that P2P moves across the internet, something that would be commercial suicide for a company that depends heavily on aggressive file sharers, and pirates, for its popularity.
The overall picture suggests that uTP has a serious flaw. If it simply relies on latency measurements to find preferred paths, it’s likely to favor paths where it’s successfully circumventing management. When a path is managed to give UDP priority over TCP (as is apparently the case in the Bell Canada network,) uTP will see that path as uncongested even as it's struggling to deliver TCP. In this case, uTP will in fact impair other applications, as we suggested in our previous piece.
--
My BLOG .. .. Internet News .. .. My Web Page
Ask yourself one question: 'Do I feel lucky?' Well, do ya punk? | | |
|
iansltx
join:2007-02-19
Golden, CO
kudos:2 | I'm sure the makers of TechCruch50 would love your description of BitTorrent. They used Vuze to share the HUGE (8+ GB each) video files for each day of the conference. Worked great, too. | |
 fireflierCoffee. . .Need CoffeePremium
join:2001-05-25
Limbo
1 edit | reply to fAcEtIOUs
I guess this is the "paradigm break in process" you've been repeatedly spewing eh?
Now the big ISPs will have no choice but to throttle the hell out of users because. . .well, because.
We're waiting for the next telcom talking point to justify traffic management. . .
Please enlighten us. | |
 jig
join:2001-01-05
Hacienda Heights, CA | reply to fAcEtIOUs
said by fAcEtIOUs:» www.theregister.co.uk/2008/12/05···ent_udp/One thing that is certain is that uTP will not reduce the volume of traffic that P2P moves across the internet, something that would be commercial suicide for a company that depends heavily on aggressive file sharers, and pirates, for its popularity.
The overall picture suggests that uTP has a serious flaw. If it simply relies on latency measurements to find preferred paths, it’s likely to favor paths where it’s successfully circumventing management. When a path is managed to give UDP priority over TCP (as is apparently the case in the Bell Canada network,) uTP will see that path as uncongested even as it's struggling to deliver TCP. In this case, uTP will in fact impair other applications, as we suggested in our previous piece.
he's missing the point. if the management is at the edges of the ISP's network (to reduce their interconnect cost, which is one of their huge issues) then IF uTP is granular enough to reduce throughput PER PEER (rather than globally for all current torrents), the client will automatically gravitate towards intra-ISP peers, which will reduce costs and extra-ISP congestion.
that's if he's right about the client being able to search out lower latency "paths" - (UDP isn't a path, but whatever). if he's not (and i don't think he is), then when it senses any congestion (he even points out that TCP and UDP both add to the overall "congestion"), it should automatically reduce traffic to allow TCP through, whether the TCP is locally generated or not. if anything, management that only affects TCP will hurt the system by creating a virtual congestion needlessly.
by itself, UDP should be easier to "switch" than almost any other protocol, so it should cause the least amount of hardware congestion/MB. this should be a win/win, except that "congestion"'s sliding scale is defined by the makers of utorrent.
it would be really interesting if uTP can throttle per peer. if it can, then the ISPs have reason to cheer - it's an automatic way to keep most of the traffic from crossing over to the backbone. | |
Reviews:
 ·Verizon FiOS
| reply to fAcEtIOUs
"One thing that is certain is that uTP will not reduce the volume of traffic that P2P moves across the internet,.."
so what? that was not the point in developing this anyway. The implicit suggestion in this statement is how P2P is devouring the internet. In fact, P2P traffic makes up less of total internet b/w than previously, with streaming video and other applications closing fast.
this guy is an incumbent shill; he should be ignored. | |
 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Clear Wireless
| reply to jig
said by jig:he's missing the point. if the management is at the edges of the ISP's network (to reduce their interconnect cost, which is one of their huge issues) I believe that to be a misread of the situation -- the carrier interconnect costs are minimal compared to the rest of the infrastructure costs.
said by jig:then IF uTP is granular enough to reduce throughput PER PEER (rather than globally for all current torrents), the client will automatically gravitate towards intra-ISP peers, which will reduce costs and extra-ISP congestion. Even if you sourced 100% of the content from the internal ISP network, you'd have the exact same subscriber access network choke points that you do today.
The problem with doing congestion sensing at the edge is that clients can only determine network impact after it is already happening. In the TCP world solutions like Random Early Discard were implemented to get TCP flows to back off before full link saturation occurs to attempt to limit the overall latency impact across all active flows. The problem is that RED will only discard TCP packets to slow down transfers because of the known guaranteed delivery status of the protocol. UDP gets a pass for a few reasons:
1) There is no layer4 recovery mechanism for drops of UDP traffic
2) Recovery at the application layer is too varied to be identified in fixed-hardware rulesets, as is the case with rigidly defined rulesets with TCP
3) There has been a general assumption that nobody would build a file transfer protocol intended for global use on UDP
Overall I expect with this we'll see history repeat itself as they hit all of the problems that TCP did during its development. What will be new this time around will be seeing the impact this will have on devices that depend on TCP flow information for their daily operations, such as routers doing pre-congestion traffic management and intelligent BGP route reflectors that use TCP flow statistics to alter the metrics used by carriers to select different BGP paths. (ie, monitor for TCP retransmissions to be able to redirect traffic around congested links)
One thing is certain - it will be interesting to see what all of the unanticipated impact will be as a large quantity of uTP traffic gets introduced into the Internet ecosystem. | |
jig
join:2001-01-05
Hacienda Heights, CA | said by espaeth:said by jig:he's missing the point. if the management is at the edges of the ISP's network (to reduce their interconnect cost, which is one of their huge issues) I believe that to be a misread of the situation -- the carrier interconnect costs are minimal compared to the rest of the infrastructure costs. even if you are right, the infrastructure costs are minimized because the p2p uTP traffic automatically meters itself appropriately IF something isn't already unbalanced in how the system deals with different protocols. regardless of whether you are right about the costs differences, the interconnect costs are what they are choosing to complain about most, lately.
said by jig:then IF uTP is granular enough to reduce throughput PER PEER (rather than globally for all current torrents), the client will automatically gravitate towards intra-ISP peers, which will reduce costs and extra-ISP congestion. Even if you sourced 100% of the content from the internal ISP network, you'd have the exact same subscriber access network choke points that you do today.
as far as the UDP specific stuff goes, UDP is a general encapsulation for custom protocols (and was originally developed as such, including as a testbed for an FTP replacement). rather than talk about what hardware mechanisms there are for UDP control, instead think about what the underlying custom protocol does; in this case, uTP. uTP should take care of congestion issues itself (again, recognizing that "congestion" is built into the protocol or the client application, and not necessarily at the control of the ISP, which may be problematic). finally, have just looked at BGP route reflectors, they seem to be dependent on TCP/IP, but i "think" the initial handshake in uTP is still over TCP. i think once the route is set up, then it can still be used for the UDP traffic. other than that, with the increase in VOIP traffic, ISPs and hardware manufacturers will eventually have to figure out how to manage traffic without relying on TCP alone anyway (or ban all non TCP, which would never be done in the US for any length of time).
--
Catapultam habeo. Nisi pecuniam omnem mihi dabis, ad caput tuum saxum immane mittam. | |
|
