NTAC Peering Working Group

[David Farmer <>]

A few things you should know, first few are fairly well known, some 
further down are less well known.

1. Amakai uses DNS magic or foo to direct where your users get their 
Akamai content.

2. They do a very good job of finding localized nodes to service you and 
to balance load across nodes, and to shed load from overloaded node.

3. If you host a local node you usually tell them the prefixes they can 
serve from your node, this can be done via BGP.  These local hosted 
nodes generally do not have AS20940 in the AS path.

4. Nodes with AS20940 is the as path are generally Akamai hosted nodes 
in general data centers, but not always.

5. If there are multiple prepends of AS20940 these routes will generally 
not be use to service you, they mostly exist to do cache fill for that 
node.  If you use Akamai's hosting services then you use these routes to 
get your content to those nodes.

6. Nodes that service you will generally only have one AS20940 in the 
path, and be fairly local to you if possible.  Of course this is 
internet topology close, not necessarily physically close, but in many 
cases it is even physically close.  And as Darrell nots on days like 
today some nodes get overload and load is pushed around to other less 
used nodes.

FYI, our local Akamai node usually runs about 2.5G and was doing about 
5G from noon to 4:00pm and has been tapering off for a couple hours now 
but still more than double for the time of day.  The local exchange 
point here in Minneapolis has an Akamai operated node and saw a similar 
spike.  Our Campus wireless when from about 1G, which is fairly typical, 
just before noon to 1.75G just after the noon hour.  Man those bit were 
flying through the air. :)

On 9/19/12 17:09 CDT, Darrell Newcomb wrote:
> Agreed John, my thoughts exactly when seeing the note.  ;-)
>
> On Sep 19, 2012, at 2:26 PM, Michael H Lambert wrote:
>
> > In looking at the TR-CPS routing table, I see a number of routes with 20940 (Akamai) in the AS 
> > path.  The vast majority of these are NOT "^11164 20940 .*".  I can't imagine that 
> > these other destinations would serve content to random sources in our community, so is there any 
> > reason that they should be accepted into the routing table?  I could imagine their presence 
> > leading to some weird return paths.  I'm assuming that "^11164 20940$" would work as 
> > expected.
>
> Good question; those announcements are mostly in two camps:
>
> 1. Where 20940 was used as origin-as in originations for devices that largely 
> service a remote user-population.
>         For example ISP in situation where they can't supply address space, 
> but is other-wise hosting the devices.  Then when using that address space 
> folks are electing to make 20940 the origin-as for those announcements (20940 
> isn't cohesive with intra-domain links, but is cohesively managed).  For 
> these you want to be able to deliver origin content from on-net systems to 
> those remote caches to have better viewing of say classroom-video archive 
> playing back in Brazil.
>
>
> 2.  Where 20940 has some-what general-purpose infrastructure and those 
> installations have upstream networks.  Networks that happen to have direct 
> interconnection with our networks.
>         These are useful for things like specialized object-types which might 
> not be widely distributed, origin-content, middle-ware, log systems, and 
> so-on.  Some of the examples in prior sentence have steady state uses, but 
> not the majority of traffic; and/or help your other on-net devices perform 
> better.   The BGP announcements of this type also cover systems that can be 
> useful for over-flow when other sources are offline or overloaded.
>
>
> Discerning between the two remotely via just BGP announcements could be quite 
> difficult. (I didn't want to go fish for in-the-wild examples in this quick 
> reply)   As well there are probably other cases than those two not 
> immediately coming to mind.
>
> But that being said you:
> 1. want solid connectivity to both of those
> 2. For most-all US R&E networks I can imagine you don't (generally) want the 
> majority of 20940 -> (your-end-user) traffic to be exchanged with those endpoints
> But (3) they might make up a non-trivial percentage of traffic and certainly 
> a non-trivial role in the larger user experience.
>
> -Darrell
>
>
> P.S. for the extra technical (and I haven't taken time to edit so will 
> apologize for the extra wordiness):
>         There are times however when the overflow demand gets shifted to 
> endpoints that seem odd on first glance.  When you look at examples of this, 
> maybe like today's software updates when overflow of individual devices/sites 
> is expected, the alternative/overflow location causes some head-scratching.  
> Many times those are trading overload of the cache nodes for a less than 
> optimal network path and in a few of those cases the realized path is not 
> terribly desirable for one or more of the parties along the way.  The easiest 
> way to tackle that is more on-net cache capacity, but if they're ever 
> particularly painful, sustained, and/or frequent w/much-better alternatives;  
> the TR-CPS advisory folks can help talk/work through improving the outcomes.

--
===============================================
David Farmer               
Email:
Office of Information Technology
University of Minnesota 
2218 University Ave SE      Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================