# RFC 016 – GeoDNS China Mainland Traffic Steering #16
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.

Summary
Authorize GeoDNS modification to route China mainland traffic from SEA region to
US West Coast (luckyfriday).
Background
Rotko Networks currently handles 34.2% of IBP GeoDNS traffic volume (12.6M
requests), approximately 13x the volume of luckyfriday (779.4K requests).
Despite 2Gbps IPv4 and 12Gbps IPv6 transit capacity, MVR alerts occur during
peak hours due to China routing inefficiencies.
China premium transit pricing ranges $30-50/Mbit/s, with $25/Mbit/s as the
floor. Current IBP Asia reimbursement rate of $0.0731/GB does not support this.
The China Boomerang
TSEA providers peer with Chinese ISPs at US West Coast exchanges. Traffic from
China to Hong Kong transits the Pacific twice aka. "the China Boomerang".
Bangkok → Hong Kong: 45ms
Hong Kong → China mainland: +180ms (US West Coast round-trip)
Measured latencies (source):
Luckyfriday US West (source):
US West Coast provides 30-50ms lower latency to China mainland than SEA
endpoints.
Proposal
Upon passing, this RFC authorizes Rotko to implement GeoDNS steering rules
routing China mainland origin traffic from SEA to luckyfriday. GEODNS in its
current state does not have this feature set, but we are more than happy to
implement it.
Load redistribution reduces peak hour pressure on highest-volume node while
improving latency for affected users.
Vote