Isn't TCP already measuring throughput and latency of the network for RTO etc.? Why not expose those parameters for peers to the local P2P
This is where you hit a serious problem. If you implemented that in a client, it could be much worse than naive P2P for quite a lot of networks - for example all the UK ISPs. If you have a bitstream/IPStream architecture, your bits get hauled from local aggregation sites to your routers via L2TP and you get billed by the telco for them; now, if you strictly localise P2P traffic, all the localised bits will be transiting the bitstream sector TWICE, drastically increasing your costs.
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. The only way for this to work is to allow the network operator to have a role in every P2P transaction. And to do that you need a middlebox that sits in the ISP network which they can configure. In the scenario above, I would expect the network operator to ban connections to their DSL address block. Instead, they would put some P2P clients in the rack with the topology guru middlebox and direct the transactions there. Or to peers/upstreams. And the network operator would manage all the block retrieval requests from the P2P clients in order to achieve both traffic shaping (rate limiting) and to ensure that multiple local clients cooperate in retrieving unique blocks from the file to reduce total traffic from upstreams/peers.
Basically, it's bringing traffic engineering inside the access network.
Actually, bringing traffic engineering into the P2P service which is where the problem exists. Or bringing the network operator into the P2P service rather than leaving the netop as a reactive outsider. --Michael Dillon _______________________________________________ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog