Re: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]
This raises an interesting issue - should optimization of p2p traffic (P4P) be based on "static" network information, or "dynamic" network information. It's certainly easier for ISP's to provide a simple network map that real-time network condition data, but the real-time data might be much more effective. Or even if it's not real-time, perhaps there could be "static" network maps reflecting conditions at different times of day? Since P4P came up, I'd like to mention that the P4P Working Group is putting together another field test, where we can quantify issues like the tradeoff between static and dynamic network data, and we would love to hear from any ISP's that would be interested in participating in that test. If you'd like the details of what it would take to participate, and what data you would get out of it, please email me. Of course, independently of the test, if you're interested in participating in the P4P Working Group, we'd love to hear from you! - Laird Popkin, CTO, Pando Networks email: laird@pando.com mobile: 646/465-0570 ----- Original Message ----- From: "Alexander Harrowell" <a.harrowell@gmail.com> To: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> Cc: nanog@nanog.org Sent: Tuesday, April 22, 2008 10:10:28 AM (GMT-0500) America/New_York Subject: Re: [Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010] Personally I consider P4P a big step forward; it's good to see Big Verizon engaging with these issues in a non-coercive fashion. Just to braindump a moment, it strikes me that it would be very useful to be able to announce preference metrics by netblock (for example, to deal with networks with varied internal cost metrics or to pref-in the CDN servers) but also risky. If that was done, client developers would be well advised to implement a check that the announcing network actually owns the netblock they are either preffing in (to send traffic via a suboptimal route/through a spook box of some kind/onto someone else's pain-point) or out (to restrict traffic from reaching somewhere); you wouldn't want a hijack, whether malicious or clue-deficient. There is every reason to encourage the use of dynamic preference. On Tue, Apr 22, 2008 at 2:54 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Apr 22, 2008 at 02:02:21PM +0100, michael.dillon@bt.com <michael.dillon@bt.com> wrote a message of 46 lines which said:
This is where all the algorithmic tinkering of the P2P software cannot solve the problem. You need a way to insert non-technical information about the network into the decision-making process.
It's strange that noone in this thread mentioned P4P yet. Isn't there someone involved in P4P at Nanog?
http://www.dcia.info/activities/p4pwg/
IMHO, the biggest issue with P4P is the one mentioned by Alexander Harrowell. After that users have been s.....d up so many times by some ISPs, will they trust this service?
_______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
_______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
On Tue, Apr 22, 2008 at 10:48 AM, Laird Popkin <laird@pando.com> wrote:
This raises an interesting issue - should optimization of p2p traffic (P4P) be based on "static" network information, or "dynamic" network information. It's certainly easier for ISP's to provide a simple network map that real-time network condition data, but the real-time data might be much more effective. Or even if it's not real-time, perhaps there could be "static" network maps reflecting conditions at different times of day?
100% solution + 100% more complexity vs 80% solution ? It strikes me that often just doing a reverse lookup on the peer address would be 'good enough' to keep things more 'local' in a network sense. Something like: 1) prefer peers with PTR's like mine (perhaps get address from a public-ish server - myipaddress.com/ipchicken.com/dshield.org) 2) prefer peers within my /24->/16 ? This does depend on what you define as 'local' as well, 'stay off my transit links' or 'stay off my last-mile' or 'stay off that godawful expensive VZ link from CHI to NYC in my backhaul network... P4P is an interesting move by Verizon, tin-hat-ness makes me think it's a method to raise costs on the direct competitors to VZ (increase usage on access-links where competitors mostly have shared access-links) but I agree with Harrowell that it's sure nice to see VZ participating in Internet things in a good way for the community. (though see tin-hat perhaps it's short-term good and long-term bad.../me puts away hat now) -Chris _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
On Wed, Apr 23, 2008 at 3:47 PM, Christopher Morrow < christopher.morrow@gmail.com> wrote:
It strikes me that often just doing a reverse lookup on the peer address would be 'good enough' to keep things more 'local' in a network sense. Something like:
1) prefer peers with PTR's like mine (perhaps get address from a public-ish server - myipaddress.com/ipchicken.com/dshield.org) 2) prefer peers within my /24->/16 ?
This does depend on what you define as 'local' as well, 'stay off my transit links' or 'stay off my last-mile' or 'stay off that godawful expensive VZ link from CHI to NYC in my backhaul network...
Well. here's your problem; depending on the architecture, the IP addressing structure doesn't necessarily map to the network's cost structure. This is why I prefer the P4P/DillTorrent announcement model. Alex _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
On Wed, Apr 23, 2008 at 11:39 AM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
On Wed, Apr 23, 2008 at 3:47 PM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
It strikes me that often just doing a reverse lookup on the peer address would be 'good enough' to keep things more 'local' in a network sense. Something like:
1) prefer peers with PTR's like mine (perhaps get address from a public-ish server - myipaddress.com/ipchicken.com/dshield.org) 2) prefer peers within my /24->/16 ?
This does depend on what you define as 'local' as well, 'stay off my transit links' or 'stay off my last-mile' or 'stay off that godawful expensive VZ link from CHI to NYC in my backhaul network...
Well. here's your problem; depending on the architecture, the IP addressing structure doesn't necessarily map to the network's cost structure. This is why I prefer the P4P/DillTorrent announcement model.
sure 80/20 rule... less complexity in the clients and some benefit(s). perhaps short term something like the above with longer term more realtime info about locality. _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
On Apr 23, 2008, at 2:17 PM, Christopher Morrow wrote:
On Wed, Apr 23, 2008 at 11:39 AM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
On Wed, Apr 23, 2008 at 3:47 PM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
It strikes me that often just doing a reverse lookup on the peer address would be 'good enough' to keep things more 'local' in a network sense. Something like:
1) prefer peers with PTR's like mine (perhaps get address from a public-ish server - myipaddress.com/ipchicken.com/dshield.org) 2) prefer peers within my /24->/16 ?
This does depend on what you define as 'local' as well, 'stay off my transit links' or 'stay off my last-mile' or 'stay off that godawful expensive VZ link from CHI to NYC in my backhaul network...
Well. here's your problem; depending on the architecture, the IP addressing structure doesn't necessarily map to the network's cost structure. This is why I prefer the P4P/DillTorrent announcement model.
sure 80/20 rule... less complexity in the clients and some benefit(s). perhaps short term something like the above with longer term more realtime info about locality.
For the applications, it's a lot less work to use a clean network map from ISP's than it is to in effect derive one from lookups to ASN, / 24, /16, pings, traceroutes, etc. The main reason to spend the effort to implement those tactics is that it's better than not doing anything. :-) Laird Popkin CTO, Pando Networks 520 Broadway, 10th floor New York, NY 10012 laird@pando.com c) 646/465-0570 _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
On Wed, Apr 23, 2008 at 3:50 PM, Laird Popkin <laird@pando.com> wrote:
On Apr 23, 2008, at 2:17 PM, Christopher Morrow wrote:
On Wed, Apr 23, 2008 at 11:39 AM, Alexander Harrowell <a.harrowell@gmail.com> wrote:
On Wed, Apr 23, 2008 at 3:47 PM, Christopher Morrow <christopher.morrow@gmail.com> wrote:
It strikes me that often just doing a reverse lookup on the peer address would be 'good enough' to keep things more 'local' in a network sense. Something like:
1) prefer peers with PTR's like mine (perhaps get address from a public-ish server - myipaddress.com/ipchicken.com/dshield.org) 2) prefer peers within my /24->/16 ?
This does depend on what you define as 'local' as well, 'stay off my transit links' or 'stay off my last-mile' or 'stay off that godawful expensive VZ link from CHI to NYC in my backhaul network...
Well. here's your problem; depending on the architecture, the IP
addressing
structure doesn't necessarily map to the network's cost structure. This is why I prefer the P4P/DillTorrent announcement model.
sure 80/20 rule... less complexity in the clients and some benefit(s). perhaps short term something like the above with longer term more realtime info about locality.
For the applications, it's a lot less work to use a clean network map from ISP's than it is to in effect derive one from lookups to ASN, /24, /16, pings, traceroutes, etc. The main reason to spend the effort to implement those tactics is that it's better than not doing anything. :-)
so.. 'not doing anything' may or may not be a good plan.. bittorrent works fine today(tm). On the other hand, asking network folks to turn over 'state secrets' (yes some folks, including doug's company) believe that their network diagrams/designs/paths are in some way 'secret' or a 'competitive advantage', so that will be a blocking factor. While, doing simple/easy things initially (most bittorrent things I've seen have <50 peers certainly there are more in some cases, but average? > or < than 100? so dns lookups or bit-wise comparisons seem cheap and easy) that get the progress going seems like a grand plan. Being blocked for the 100% solution and not making progress/showing-benefit seems bad :( -Chris _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Well. here's your problem; depending on the architecture, the IP addressing structure doesn't necessarily map to the network's cost structure. This is why I prefer the P4P/DillTorrent announcement model.
What's with these cute cryptic and ultimately meaningless names? I used the term "topology guru" because I wanted something that halfway describes what is going on. Coining a word with "torrent" in it is wrong because this kind of topology guru can be used with any P2P protocol. And P4P seems more like a brand name that tries to leverage off the term P2P. --Michael Dillon _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
On 4/23/08, michael.dillon@bt.com <michael.dillon@bt.com> wrote:
Well. here's your problem; depending on the architecture, the IP addressing structure doesn't necessarily map to the network's cost structure. This is why I prefer the P4P/DillTorrent announcement model.
What's with these cute cryptic and ultimately meaningless names?
I used the term "topology guru" because I wanted something that halfway describes what is going on. Coining a word with "torrent" in it is wrong because this kind of topology guru can be used with any P2P protocol. And P4P seems more like a brand name that tries to leverage off the term P2P.
--Michael Dillon
Perhaps call it TopoMaster, and make it an open protocol that any app that
needs to move lots o' bits around can use. -brandon _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
participants (6)
-
Alexander Harrowell -
Brandon Galbraith -
Christopher Morrow -
Christopher Morrow -
Laird Popkin -
michael.dillon＠bt.com