NTAC Peering Working Group

[Jeff Bartig <>]

Peering & Routing WG Members,

I've been working with Apple since the iOS9 release on issues
relating to where their geolocation algorithm is directing users
to download software updates.  Many R&E networks were seeing Apple
direct their users to Apple download servers that were only available
via their paid transit and not via TR/CPS or even local peering the
R&E might have with Apple.

Apple has made some additional changes in the last 24 hours to their
geolocation mapping.  They are requesting that R&E networks test
this and report any issues.  I've created a spreadsheet where I've
been having various R&E networks record the results of DNS queries:

https://docs.google.com/spreadsheets/d/1V5cBpmwlWRf0eq4kvl0ctcMDMklyAAB8e8gxTMexQY0/edit?usp=sharing

If you have a few minutes and could contribute some data, I would
appreciate it.  I'm basically asking for you to look up the DNS A
record for "appldnld.apple.com" and then look up the PTR record for
one of the returned addresses.  Both the A and PTR results can be
appended to the above spreadsheet along with time and location
details.

Apple has pointed out some other issues that may be impacting R&E
networks receiving Apple traffic via TR/CPS or their own local
peering with Apple:

1.  AS Path Prepending:  in some cases, Apple is seeing the same
length AS path to a campus via both TR/CPS and a network the campus
buys transit from.  If this network is one that settlement-free
peers with Apple, Apple will treat it the same as TR/CPS and may
choose that path over TR/CPS.  I think a common example of this may
be Hurricane Electric paid transit.  Prepending towards paid transit
can encourage traffic to route via TR/CPS, rather than via paid
transit.

2.  Apple is using an end user's DNS resolver IP (recursive DNS
server) for Geolocation and determining the best path for routing
to the user.  If the IP network of the DNS server and the IP network
of the end user are advertised differently via BGP, Apple may pick
a poor path to the end user.

3.  Apple has now established dual routers and server clusters in
each major city where they peer.  These routers/servers apparently
are not interconnected.  If you are directed to one cluster, but
peer with the other, the traffic from Apple may end up taking transit
to reach the end user, even though there is local peering.  Internet2
TR/CPS is working on establishing peering with both clusters in
every city where we privately interconnect with Apple to address
this issue.

Thanks for your help,

Jeff

-- 
Jeff Bartig
University of Wisconsin

(608) 262-8336