Slashdot Mirror


Enhancement To P2P Cuts Network Costs

psycho12345 sends in an article in News.com on a study, sponsored by Verizon and Yale, finding that if P2P software is written more 'intelligently' (by localizing requests), the effect of bandwidth hogging is vastly reduced. According to the study, redoing the P2P into what they call P4P can reduce the number of 'hops' by an average of 400%. With localized P4P, less of the sharing occurs over large distances, instead making requests of nearby clients (geographically). The NYTimes covers the development from the practical standpoint of Verizon's agreement with P2P company Pando Networks, which will be involved in distributing NBC television shows next month. So the network efficiencies will accrue to legal P2P content, not to downloads from The Pirate Bay.

8 of 190 comments (clear)

  1. 400%? by Sam+H · · Score: 5, Insightful

    How do you reduce the number of 'hops' by an average of 400%? Negative number of hops? Also, FP.

    --
    God, root, what is difference ?
    1. Re:400%? by MightyYar · · Score: 5, Funny

      Well, this being Slashdot, I couldn't exactly read the article, now could I? Instead, I opened the article and searched for "4".

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
    2. Re:400%? by ThreeGigs · · Score: 5, Insightful

      It gets worse. From RTFA:

      "Using the P4P protocol, those same files took an average of 0.89 hops"

      How do you possibly get an average of LESS than one hop, unless you're getting the file from yourself?

    3. Re:400%? by laird · · Score: 5, Informative

      Speaking as the guy that ran the test, I should explain the "hop count" decrease observed in the test in more detail than the article. First, I should clarify that the 'hop' is a long-distance link between metro areas, because that is the resource that is scarce - we ignored router hops, because they aren't meaningful, and generally aren't visible inside ISP infrastructures for security reasons. This means that data that moves within a metro area is zero hops, data pulled from a directly connected area is one 'hop', and so on.

      So in the field testt we saw data transmission distance drop from an average of 5.5 'hops' to 0.89 'hops'. This happens because P4P provides network mapping information, allowing the p2p network to encourage localized data transfers. Generic p2p moved only 6.27% of data within a metro area, while p4p intelligence resulted in 57.98% same-metro area data transfer. Thus deliveries are both faster and cheaper.

  2. Re:P2P - P4P? by TripMaster+Monkey · · Score: 5, Insightful

    Well, strictly speaking, incrementing the number would result in P3P, not P4P. Just as P2P means "Peer to Peer", P4P could be interpreted as "Peer for Peer", justifying the numeral.

    --
    ____

    ~ |rip/\/\aster /\/\onkey

  3. Re:P2P - P4P? by ePhil_One · · Score: 5, Funny
    Well, strictly speaking, incrementing the number would result in P3P, not P4P. Just as P2P means "Peer to Peer", P4P could be interpreted as "Peer for Peer", justifying the numeral.

    Personally I'm waiting for the next binary progression, Peer Ate Peer, or P8P. I'm not sure what it will do, but I'll bring popcorn to watch...

    --
    You are in a maze of twisted little posts, all alike.
  4. Re:New math by MightyYar · · Score: 5, Informative

    I think I figured out their math, and you aren't going to like it:

    5.5 * 0.89 - 0.89 = 4.0050 or 400%

    As opposed to:

    ( 5.5 - 0.89 ) / 5.5 = 84%

    --
    W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  5. Re:What information are we talking about? by mr_mischief · · Score: 5, Informative

    You seem so certain.

    Your traceroute program doesn't tell you when your traffic is being routed four hops through a tunnel to cut down on visible hops and to save space in the ISP's main routing table. Without the routing tables at hand you don't know the chances of being routed through your usual preferred route and through a backup route kept in case of congestion. Nothing from the customer end shows where companies like Level 3 and Internap have three or four layers of physical switches with VLANs piled on top between any two routers. Nothing tells you when you're in a star build-out of ten mid-sized cities that all go to the same NOC vs. when you're being mesh routed over lowest latency-weight round robin, although you might guess by statistical analysis and mesh routing of commercial ISP traffic outside the main NAPs is getting more and more rare.

    There's a lot you can easily deduce, especially if your ISP uses honest and informative PTR records. There's still much that an ISP can do that you'll never, ever know about.

    I worked for one ISP where we had 5 Internet connections in four cities to three carriers, but we served 25 cities with them. We had point-to-point lines from our dial-in equipment back to our public-facing NOCs. We had a further 18 or so cities served by having the lines back-hauled from those towns to our dial-in equipment. We had about 12k dialup customers and a few hundred DS1, fractional DS1, frame relay, and DSL customers. Everyone's traffic went through one of two main NOCs on a good day, and their mail, DNS, AAA, and the company's web site traffic never touched the public Internet unless we were routing around trouble. In a couple of places we even put RADIUS slaves and DNS caching servers right in the POP.

    I worked for another that served over 40k dial-up and wireless customers by the time they sold. We had what we called "island POPs". Each local calling area we served had dial-in equipment and a public-facing 'Net connection. Authentication, Authorization, and Accounting, DNS, Mail, and the ISP's website traffic all flowed over the public Internet except in the two towns we had actual NOCs. There were tunnels set up between routers that made traffic from the remote sites to the NOCs look like local traffic on traceroute, but that was mainly for our ease of routing and to be able to redirect people to the internal notification site when they needed to pay their late bills. We (I, actually) also set up L2TP so that we could use dial-up pools from companies like CISP who would encapsulate a dial-in session over IP, authenticate it against our RADIUS, and then allow the user to surf from their network. We paid per average used port per month to let someone else handle the customer's net connection while we handled marketing, billing, and support.

    The first ISP I worked for had lines to four different carriers in four different NAPs in four different states, lots of point-to-point lines for POPs, and a high-speed wireless (4-7 MBps, depending on weather, flocks of birds, and such) link across a major river to tie together two NOCs in two states. Either NOC could route all of the traffic for all the dozens of small towns in both states as long as one of our four main connections and that wireless stayed up (and all the point-to-point ones did, too). If the wireless went down, the two halves of the network could still talk, but over the public Internet. That one got to about 10k customers before it was sold.

    At any of those ISPs, I couldn't tell you exactly who was going to be able to get online or where they were going to be able to get to without my status monitoring systems. On one, all the customers could get online even without the ISP having access to the Internet, but they could only see resources hosted at the ISP. Yet that one might drop five towns from a single cable break. Another one might keep 10k people offline due to a routing issue at a tier-1 NAP, but everyone else was okay. However, if that one's NOC went offline, anyone surfing in other