- NANOG - lists.nanog.org

Re: Peering Policy ( was Re: AGIS/DIGEX )
by Scott Huddle 30 Oct '96

30 Oct '96

Michael Dillon <michael(a)memra.com> wrote > > On Wed, 30 Oct 1996, Scott Huddle wrote: > > > > > Applying lets say 1 cent per 100 bit charge, AAA gets $455.64 from BBB > > > > > > > So here is my question -- why is this kind of arrangement not being used > > > > anywhere??? > > > > > > The bookkeeping costs $2000 per month for *BOTH* providers to monitor > > > this, collect data, collect bills, etc.... > > > > Source of data, please? > > Same source as the other guy's data. I pulled it out of thin air. > Actually, I figured $2,000 per month would be an appropriate salary for > one clerk to handle this job. > > And the point was that managing settlements costs money. We know that in > the POTS system the costs of usage based billing are at least 50% of the > total. OK, do you have a source for the POTs number? -scott

2 1

Re: Peering Policy ( was Re: AGIS/DIGEX )
by Scott Huddle 30 Oct '96

30 Oct '96

Michael Dillon <michael(a)memra.com> wrote > On Wed, 30 Oct 1996, Pritish Shah wrote: > > > Applying lets say 1 cent per 100 bit charge, AAA gets $455.64 from BBB > > > So here is my question -- why is this kind of arrangement not being used > > anywhere??? > > The bookkeeping costs $2000 per month for *BOTH* providers to monitor > this, collect data, collect bills, etc.... Source of data, please? -scott

3 2

Bit-dumping [Was: Re: Peering Policy]
by Paul Ferguson 30 Oct '96

30 Oct '96

Apparently people are still missing the point. On a shared media exchange, there is nothing to preclude another entity from pointing default to you even if they are *not* peering with you [a.k.a. bit-dumping]. - paul At 11:15 AM 10/30/96 -0500, Pritish Shah wrote: > >So far from what I have gathered, everyone is afraid of being used as a >transit point. There is a very simple solution available which I can't >figure out why people are not using. > >Both peers charge each other for the bits being peered. So now if one >peer is being used as a transit point, then they get compensated for it. > >Eg > >AAA BBB >15443621 bits -> 15443621 bits >20000000 bits <- 20000000 bits > > >Difference 4556379 bits additional sent from BBB to AAA > >Applying lets say 1 cent per 100 bit charge, AAA gets $455.64 from BBB > >Simple!!!! > >Now with this kind of peering arrangement, no one has to be worried about >being used as a transit point -- infact they will want to be used as a >transit point. > >This will also allow medium sized ISPs to peer with each-other. > >So here is my question -- why is this kind of arrangement not being used >anywhere??? > >Pritish >

7 9

Re: AGIS/DIGEX
by matthew＠scruz.net 30 Oct '96

30 Oct '96

This exact thought has occured to me. Fixed charges to peer at fewer places. You can even come up with reasonable assumptions for fixed charges. (like that people who peer at one coast but not the other are costing you some fraction of one direction of a coast-to-coast DS3, and ought to pay you about that much) Perhaps if/when we end up at additional NAPs we'll implement this policy ourselves. -matthew kaufman matthew(a)scruz.net Original message <Pine.ULT.3.93.961030093058.20904H-100000(a)halcyon.halcyon.com> From: Ed Morin <edm(a)halcyon.com> Date: Oct 30, 9:32 Subject: Re: AGIS/DIGEX > > Maybe a peering agreement that has settlements based on the number of > NAP's you peer at? Peering at _no_ NAP's means paying full price with > a decreasing scale down to nothing if you peer at 5 NAP's (or whatever > the current hurdle is set at). > > Ed >

1 0

Re: AGIS/DIGEX
by Mark Borchers 30 Oct '96

30 Oct '96

> AGIS has made it a 5-NAP requirement - and the AADS and PacBell NAPs > are not the easiest to get into on 1-day notice. > What I heard them say was that you had to peer with them in every NAP where they were present...implying that if they go into a sixth NAP, their peering requirement increases. Mark Borchers InfiNet Network Engineering NOC: (757) 624-2295 ext. 3007

6 6

Re: A proposal for reducing routes due to multihoming
by Tony Li 30 Oct '96

30 Oct '96

The first time I heard this idea was last year, from Noel Chiappa. Joel Halpern and I spent a while discussing it and decided it would scale surprisingly well. However, why would the major providers be motivated to implement it at all? Because it reduces routes... and it has other benefits, such as allowing subscribers to change providers within the provider group without renumbering. If you still have a copy of Yakov's ID on stratum based aggregation, you might check that out. Sorry, it's expired and I don't have a copy myself. Yakov and I are discussing overhauling the document and resubmitting it. Tony

1 0

Re: AGIS/DIGEX
by Tony Li 30 Oct '96

30 Oct '96

Others have said this, but it really does seem like there needs to be pricing that allows for varying degrees of peering. It's a big jump from "you pay for every byte" to "you pay us nothing". There are providers who should fall between these extremes. Rest assured that in the fullness of time, such providers will exist. The market will force it. In the mean time, smaller providers who would like to encourage such practices have a rather persuasive inducement towards such a behavior: on your peering application, attach a check. Tony

1 0

Re: AGIS/DIGEX
by Steve Noble 30 Oct '96

30 Oct '96

At 10:36 AM 10/30/96 +0500, you wrote: >> AGIS has made it a 5-NAP requirement - and the AADS and PacBell NAPs >> are not the easiest to get into on 1-day notice. >> >What I heard them say was that you had to peer with them in every NAP >where they were present...implying that if they go into a sixth NAP, >their peering requirement increases. > actually peter said something about if you weren't at every nap they were at, there might be problems (or they have seen problems) getting traffic to/from you. That's kind of a scary (and unrealistic) thought imho to think that their/your/the internet is so unstable that out of 6 paths only 1 functions correctly. .-[ Steve Noble / Sr.Network Admin ]-. - Exodus Communications / steve(a)exodus.net - - v(408)486-5024 / f(408)486-5001 -

1 0

RE: A proposal for reducing routes due to multihoming
by Peter Cole 30 Oct '96

30 Oct '96

I think you miss the whole reason that we want multihoming. We want higher reliability. If you use one block for both providers say Sprint and MCI then when Fortworth takes another fiber cut (happens every few months) Sprint will bitbucket traffic that arrives inside their network for my system. Or if I see that one provider is flapping nationwide then I withdraw my routes and down the interface to that provider. That is how I see higher reliability. ---------- From: Alexis Rosen[SMTP:alexis@panix.com] Sent: Tuesday, October 29, 1996 10:27 AM To: nanog(a)merit.edu Subject: A proposal for reducing routes due to multihoming Bill Simpson claims that this idea is ~10 years old, but if so perhaps it's time to air it again. I thought of this during the route flap BOF at NANOG, mentioned it, and nobody came up with any immediate reasons why it wouldn't work, so I'm sending it to the list for further consideration. It's dead simple, really: Assign address blocks to pairs of providers. Both providers announce those blocks all the time, and assign addresses out of those blocks to customers who multihome between those two providers. Now, clearly this won't help all multihomed nets, because you can't possibly provide netblocks for all provider pairs- you'd have n*n-1 blocks instead of n, for n providers- but you can optimize for common cases. In particular, any two providers who will state that they are going to coordinate multihoming get a netblock. You can also limit this, at least in the beginning, to some smallish group of providers (such as the big six/seven/whatever, though that's probably a poor criterion). Any provider who wants to start doing this today can, of course, simply by declaring that part of its aggregate is now jointly owned by another provider, and that other provider announcing that part. This isn't really a change in technology so much as it is a change in bookkeeping: by putting all the multihomed nets together, both of the providers of those multihomed nets can aggregate announcements. But the benefit is real: fewer routes, and no route flaps when any single multihomed customer falls off the net. You reach breakeven on # of routes as soon as any pair of providers has two customers doing multihoming. That makes this scheme beneficial both to customers and to providers. So, any takers? /a

1 0

Re: Peering Policy ( was Re: AGIS/DIGEX )
by owen＠DeLong.SJ.CA.US 30 Oct '96

30 Oct '96

> So far from what I have gathered, everyone is afraid of being used as a > transit point. There is a very simple solution available which I can't > figure out why people are not using. > > Both peers charge each other for the bits being peered. So now if one > peer is being used as a transit point, then they get compensated for it. > > Eg > > AAA BBB > 15443621 bits -> 15443621 bits > 20000000 bits <- 20000000 bits > > This is not simple or correct. For example, we host MicroSoft's download site for Internet Explorer. Should we pay the price for all the bits we deliver to AAA in response to AAA's customers requests for Internet Explorer? I don't think so. > Difference 4556379 bits additional sent from BBB to AAA > > Applying lets say 1 cent per 100 bit charge, AAA gets $455.64 from BBB > > Simple!!!! > > Now with this kind of peering arrangement, no one has to be worried about > being used as a transit point -- infact they will want to be used as a > transit point. > Why heck, it would even make the $5/month personal accounts proffitable, as you would get reimbursed by all the ISP's your customers download from. > This will also allow medium sized ISPs to peer with each-other. > > So here is my question -- why is this kind of arrangement not being used > anywhere??? > Because it's a broken idea. > Pritish > > > > Owen

1 0