SFI/SBI/Transit - Dumping

Matthew Petach mpetach at netflight.com
Tue Mar 16 21:36:36 UTC 2021


On Tue, Mar 16, 2021 at 3:33 AM Douglas Fischer <fischerdouglas at gmail.com>
wrote:

> There is no specific story on the focus.
> My objective is to go a bit beyond the technical aspects of Peering, or
> De-peering.
>
> At the first moment, I don't mention some cases that I have in mind,
> exactly to avoid the polemic and focus on the aspects around the cases.
>
> I will give a hypothetic example, with no real names:
>
> ---
> The "SteveAndEdNet", a CDN Company, decides to extend its branchs until
> "Kingdom of Far Far Away", and creates a POP there.
> Installs itself on "DorisInnDatacenter", connects with some IXPs over
> there, connects some PNIs with some nobles.
> But, after some time, "SteveAndEdNet" make a deal with "RumpelstiltkinNet"
> a Transit provider that operates there.
>
> On that deal "RumpelstiltkinNet" ensure to supply the traffic demanded to
> "SteveAndEdNet" POP to be considered technical justifiable...
> But it also demands, that "SteveAndEdNet" drain all the traffic to IXPs
> and PNIs...
> With that, "RumpelstiltkinNet" can be the only one reseller of the content
> delivered by "SteveAndEdNet".
> ---
> This is a foggy example that I'm trying to understand better by the point
> of view of Economics Dumping.
>
> And then??
> Can this be considered an anti-competitive act?
>
>
>
> If anyone feels more comfortable reaching me privately, no issues with
> that.
>


Hi Douglas,

I've been involved in negotiations with country-level providers that
engaged in negotiation tactics like that.

>From the content-provider side, such demands (ie, drain all traffic away
from IXPs and other SFI PNIs)
might last a short time, if RSN (RumpleStiltskinNet) undercuts the pricing
so low on their connectivity
that it makes sense to move all the traffic over, or bundles in other
products (power, space, remote
management, etc.) so that the overall package price is lower than it would
be if the IXP and SFI PNIs
were maintained.

However, such relationships tend to fall apart the first time RSN has a
large-scale outage
that negatively impacts the CDN and all its content customers, at which
point the
negotiation table is usually re-opened, and the CDN says "in order to
protect our
customers from your ineptitude, we require alternate pathways for the
content to
be served in your region" -- and the exclusive arrangement goes away.

The simple fact of the matter is that in general, agreeing to single-home
your
content behind a single provider results in reduced availability for the
content, as
a single provider has less redundancy and less diversity than a blend of
multiple
providers, whether paid or settlement free.  And once a major outage
happens
that threatens the top-line revenue numbers for the CDN, saving money on
the
bottom line suddenly becomes much less important than preserving the
top-line
revenue number.

There's a finite and limited benefit RSN can offer by reducing cost
numbers;
but there's a potentially *unlimited* upside risk.  That is, RSN can't
reduce
your cost numbers from what they are today to less than zero; so there's a
maximum benefit they can offer.  But if they have a bad week, and you go
dark, and lose all your customers, you could lose all your revenue--and
there's
no limit on how much you could lose on that end, as your customer base and
revenue numbers go up.

Thus, on balance, such agreements don't last, as either the CDN goes out
of business, and the agreement thus ends, or the CDN becomes more
successful, and the top-line revenue dollar value risk outweighs the
offered cost-reduction saving benefit RSN is bringing to the table,
and the agreement is thus terminated.

I hope this helps clear up the situation for you.   :)

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210316/778c9762/attachment.html>


More information about the NANOG mailing list