[Nanog] Lies, Damned Lies, and Statistics [Was: Re: ATT VP: Internet to hit capacity by 2010]

Tue Apr 22 13:02:21 UTC 2008

> 	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