I've had some discussions with the board as well as with Jay and Jeremy
on these topics. The board consensus was to bring this (in general) to
the membership for more input.
As to the specifics, while I know others agree with at least parts of
this, I'm only speaking for myself here. I'll let everyone articulate
their own positions. (This disclaimer should not be read as me signaling
the existance of disagreement either. I just don't want to put words in
other people's mouths.)
Our current policy on remote switches is here:
https://micemn.net/technical.html#remotes It has the proposal presented
to the membership for discussion, then the board makes a final decision.
Is this decision ministerial or discretionary? That is, if the remote
switch proposal checks all the boxes in our policy, is MICE "required"
(supposed to) always grant it, or is the board supposed to apply some
discretion?
If the decision is ministerial, then why bother bringing this to the
board (or for that matter, the members) all? Couldn't we save a bunch of
time and hassle and simply have management (in some form, whether that's
me, Jay, and/or Jeremy) approve it?
If the decision is discretionary, are there particular criteria that the
board should consider (above and beyond the listed criteria)?
One criteria used in a discussion I had (and I can't recall which of us
said it first) is "MICE's strategic interests". What would that phrase
mean to you; what are some strategic interests of MICE?
For a bit of an absurd example for the thought experiment, imagine
that someone was proposing a MICE remote switch, but we knew their
goal was to attract a bunch of members and then convert that into a
competing exchange. Is that something we would have to agree to
simply because they met all the objective criteria?
When we were new and little, MICE certainly had an interest in
making every decision in a way that would maximize additional
peering. However, at this point, the calculus may be (I'd argue is)
different. We are moving a lot of traffic and are important to our
members / in our region. We have to be careful that our decisions do
not destabilize the exchange--in multiple ways: technical,
financial, or political.
Either way, should we expand the list of objective criteria in the
policy? Some examples:
* We have previously discussed dedicated vs non-dedicated switches. As
time goes along, I am more convinced than ever that MICE remote
switches should be required to be dedicated. Non-dedicated switches
present extra complications for configuration and troubleshooting.
(Jeremy has some additional insight on this that he will share.) I
think we should make it a requirement that the switch be dedicated.
(Perhaps the board could still grant an exception in exceptional cases.)
* Should we require that a remote switch have X number of participants
committed? And if so, what is X? In my view, it hardly makes sense
to have a remote switch one or two participants. They could just as
well backhaul to MICE directly.
The criteria for allowing new remote switches vs disconnecting existing
remotes need not be the same. If we set a minimum of e.g. 5
participants, we don't necessarily need to disconnect existing remotes
that don't meet that. And I think the consensus is that we would not,
barring them creating some significant problem.
How do we feel about far-away remote switches? (This is a live issue in
the context of the proposed Kansas City remote.)
Some concerns:
* At Wiktel, I peer with MN VoIP's far away extensions in Minneapolis.
For example, I peer at SeattleIX (SIX) in Minneapolis. This has
caused me some issues. For example, latency-sensitive gaming traffic
was tromboning
Wiktel-Minneapolis-Seattle-Chicago-Seattle-Minneapolis-Wiktel rather
than Wiktel-Chicago-Wiktel.
* Is it safe to have a broadcast domain that stretches across multiple
states (or half a continent, in the SIX case)?
* If we take this to its logical extreme... Imagine we had a MICE
extension in every datacenter in the U.S. I think that is pretty
obviously untenable for a bunch of reasons. Something close to that
is actually within the realm of possibility, with some of these
virtual extension things that people are doing. (Reid would be able
to cite who.) Granted, nobody is proposing that today, but where
should we draw the line?
* Far-away extensions may reduce the incentive for CDNs to install
locally.
Some counterpoints:
* Nobody is forcing networks to use the far-away remotes.
* If people choose to use them, they take their routing into their own
hands. They need to understand the tromboning risk and set their own
routing policy.
o Counter-counterpoint: Do they? Especially smaller / less
experienced networks? Have we adequately warned them?
o Counter-counterpoint: The existence of these far-away peers
doesn't affect just them. It also affects the other networks
with which they peer. Everyone on the exchange needs to be aware
of the existence of far-away participants and handle their
routing policy accordingly. If there are enough far-away peers,
this might tip networks into an opt-in route server policy, or
even to only do bilaterals. This will disadvantage small
participants.
* Networks can backhaul into far-away exchanges directly.
o Counter-counterpoint: But a remote switch makes this cheaper /
more feasible / more common, which is literally the point of
creating such a remote switch.
* For a local eyeball network in Des Moines, neither MICE nor Kansas
City are far-away from me. Even MICE via Kansas City is not likely
to be problematic. This might be the only economically feasible way
they could peer with Minneapolis content.
--
Richard
