Thanks Richard for this great summary of what the board has been pondering for a bit... Reid On Thu, Mar 24, 2022 at 4:58 PM Richard Laager <[log in to unmask]> wrote: > 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. > - Counter-counterpoint: Do they? Especially smaller / less > experienced networks? Have we adequately warned them? > - 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. > - 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 > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178