Toll-Free 855 allocations by “Randomized Round Robin”
Vanity International, a consultancy and small RespOrg, hereby submits comments in response to the Commission’s Public Notice; DA 10-1604 in CC Docket 95-155 released August 27, 2010.
We do not support “rationing” of 855 numbers per se, as we believe rationing will not have the desired effect; “to ensure that all parties have equal access to the new 855 toll free numbers.” Further, it’s clear from a majority of the comments submitted thus far that this approach is being fostered by a write-in campaign promoted by just one RespOrg without MGI access, TollFreeNumbers.Com.
Indeed, fixed daily “rationing” would disadvantage major carriers like AT&T, Verizon, Sprint, Qwest, and others constrained to 500 or 1,000 per entity—regardless of size or customer base (Does AT&T not have “real customers,” too, that “need to build their businesses?”). Further, a fixed ration of great numbers is just as appealing as an unlimited amount, so why would any of the participants dial back their automation?
Rather, we propose that the FCC direct DSMI to adopt an off-line allocation process called, “Randomizing Round Robin,” as this permits each RespOrg to submit as many numbers as they need while ensuring that all participants have “equal access.”
The Introduction of 855 numbers will allow some of the most sought-after numbers to be acquired; numbers, for example, that map to vanity overlays like 855-Flowers, 855-Doctors, 855-Dentist, as well as easy to dial numbers like 855-555-5555 and others. There will, therefore, be a momentary spike in demand as the best 5-12% of the 855 numbers are reserved immediately upon the code opening. Beyond that, there’s no reason to assume the weekly demand will be any greater then it had been before the launch.
The fact is that a code opening is anomaly. “Rationing” is not a viable solution, as it does nothing to avert those with most powerful connections from getting first pick of the best available numbers – and overwhelming the SMS/800 system with real-time requests. Indeed, “rationing” will simply result in daily system jams for as many days as it takes to satisfy demand.
Those with slower or manual connections would still get “leftovers,” only now on a daily or weekly basis rather than en masse at the release. The fact is that RespOrg do not have “equal access” speeds, so there is no dynamic way to ensure “equal access” to 855 toll free numbers.
Rather, we propose an allocation method recently used in the “land rush” of .info/.biz Internet domains called a, “randomized round robin,” which naturally averts the need for rationing. In effect, this approach emulates a “rationing” of one request per RespOrg and truly levels the playing field for all participants.
In a Randomized Round Robin (RRR), each RespOrg submits a single, comprehensive list of all requested 855 numbers in digital form – as many 855 requests as desired -- by a date and time certain, say, by noon, Oct 2, 2010. From the standpoint of the RespOrg, this is exactly what they must be prepared to do anyway, so there’s no need to extend the timeframe.
Once submitted, the Help Desk would then “randomize” the order of each digital list. This is key, and ensures that submitted numbers are not processed in any order of preference and that the best numbers are not all reserved in the first round.
The round robin order is also randomized, ensuring that each RespOrg has an equal change of drawing first, second, and so forth. All participating RespOrgs get one 855 request in each round, from their now randomized request list. This initial, random order is then maintained round after round.
As the RRR proceeds, each unreserved 855 request becomes a reservation. However, when an 855 request comes up that is already reserved, that RespOrg loses that round and gets no reservation—just as though they had requested a reserved number in real time that was already taken. The round robin continues until all lists are exhausted, ultimately processing the tail end of the longest submitted list.
This is all done off-line and the “success” list is batched by the Help Desk and placed in “Reserve” status for the requesting RespOrg.
Key Advantages are:
- All RespOrgs gain “equal access,” regardless of technology, bandwidth, programming, or size.
- Randomizing whom, “comes first” preserves, “First come, first serve”.
- The process naturally limits reservations to one each round, so there’s no need for “rationing,” yet all demand is satisfied en masse.
- RespOrgs can submit all desired numbers by the deadline and not staff over the weekend of October 2, 2010.
- If the largest or smallest RespOrgs somehow feel disadvantaged by this attempt at “equal access,” it is essential to note that “real customers” are in no way disadvantaged; they can place their order with any RespOrg they like.
- Lists are randomizes so that there is no advantage to seeding the best selections first. Great numbers will still be available in later rounds!
- The draw order is randomized so all RespOrgs have any equal chance becoming the first to draw.
- The Help Desk can conduct the RRR off-line with a spreadsheet or simple database, then simply reserve the successful list of numbers with a batch submission, prior the actual code opening.
- Code opens with virtually all competitive reservations in place.
- Opening system load is minimized – and access priority is not at issue -- but should still take place on a weekend.
Key Contraints are:
- One request per primary RespOrg per round, regardless of size.
- Sub-RespOrgs must feed through the primary RespOrg.
- Primary RespOrgs put in place after September 1, 2010 – or even earlier -- cannot be allowed to participate in the RRR, or RespOrgs will have an incentive to add RespOrgs to increase their success rates.
- If a RRR is adopted, there is no need for additional notice or to move the date of submission. However, the actual code opening will be pushed back a week or two.
- There is no need or rationale to include a trademark holders “sunrise” period for 855 numbers as they did with the .info/.biz domains.
- All Help Desk randomization should be done in supervised teams to ensure the integrity of the process.