BBN/GTEI

Fri Aug 21 22:44:24 UTC 1998

Has anyone yet come up with any good metrics for route-miles a packet 
must pass through in one direction or another? 

Right now, the closest thing I have seen to that is MEDs in a BGP 
announcement, set by a provider who knows a little something about how 
his network is built. 

The problem I see is that if we base settlement on how the MEDs are set, 
an unscrupulous peer could change his MEDs to offset a portion of his 
transit or something along those lines.

Or every content provider could buy a same-sized access provider or vice 
versa, and solve the problem that way.

-Deepak.

On Fri, 21 Aug 1998, Michael Dillon wrote:

> On Fri, 21 Aug 1998, Karl Denninger wrote:
> 
> > In fact, what you're advocating is billing the sender for *solicited data*
> > from the recipient's point of view! 
> 
> Not at all. I am advocating paying for transit. When A and B use roughly
> the same amount of each other's transit, there is no point in counting the
> difference. But when you have an asymmetric situation, rather than cutting
> off peering altogether because the other guy is too different, why not
> have a scalable peering situation that directly addresses the asymmetry in
> traffic flows. The only other solution that I can see is for the network
> receiving the huge incoming flow to direct all that web traffic through
> transparent web caches at each exchange point. However that just raises
> increased barriers to peering and does not deal with non-cacheable
> dataflows which are increasing over time. Scalable peering would reduce
> the barriers to peering and make it easier for new players to buy in. They
> would still have to build a truly national network, but at that point they
> could not have the door slammed in their faces.
> 
> Regardless of whether my proposed solution is the correct one or just a
> bad idea produced by indigestion, you cannot deny that the asymmetry
> between networks is increasing as network providers specialize the
> services they offer. The old-fashioned rough-cut peering is becoming more
> and more unsuitable as the only peering option. We need new ways to do
> this. Somebody has to take the first step. Somebody has to be a pioneer.
> 
> The details can always be hashed out later.
> 
> --
> Michael Dillon                 -               Internet & ISP Consulting
> Memra Communications Inc.      -               E-mail: michael at memra.com
> Check the website for my Internet World articles -  http://www.memra.com        
> 
> 
> 