[19018] in North American Network Operators' Group
Re: BBN/GTEI
daemon@ATHENA.MIT.EDU (Robert Bowman)
Tue Aug 25 10:40:18 1998
From: Robert Bowman <rob@elite.exodus.net>
To: michael@memra.com (Michael Dillon)
Date: Fri, 21 Aug 1998 15:59:30 -0700 (PDT)
Cc: nanog@merit.edu
In-Reply-To: <Pine.BSI.3.93.980821152743.701w-100000@sidhe.memra.com> from "Michael Dillon" at Aug 21, 98 03:36:08 pm
Isn't being a pioneer doing best-exit to eliminate the cost imbalances?
I thought that was the whole idea behind what BBN/Exodus were doing.
>
> 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@memra.com
> Check the website for my Internet World articles - http://www.memra.com
>
>
