Re: [Ila] [5gangip] Scaling mapping systems (was Re: BOF Description)

["FIGURELLE, TERRY F" <[e-mail]>]

You have a scaling problem there since you can handle that traffic example on much less than 530 UPF’s (e.g. 20+20 is enough from capacity point of view). To cover all of the layer1 fiber paths of importance in continental US you only need a max of 180 locations. I doubt anyone but AT&T would go to that extreme on fiber plant connectivity. Adding more locations actually increases latency and is not desired.

From: 5gangip <[e-mail]> On Behalf Of Tom Herbert
Sent: Tuesday, February 06, 2018 12:28 PM
To: Lorenzo Colitti <[e-mail]>
Cc: Tom Herbert <[e-mail]>; [e-mail]; Alexandre Petrescu <[e-mail]>; Behcet Sarikaya <[e-mail]>; Dino Farinacci <[e-mail]>; 5GANGIP <[e-mail]>
Subject: Re: [5gangip] [Ila] Scaling mapping systems (was Re: BOF Description)



On Mon, Feb 5, 2018 at 10:34 PM, Lorenzo Colitti <[e-mail]<mailto:[e-mail]>> wrote:
On Tue, Feb 6, 2018 at 12:37 AM, Tom Herbert <[e-mail]<mailto:[e-mail]>> wrote:
As time has gone on with experience in deployment, forwarding to another node that has a large shared cache, like an RTR, seems to deal with the issue in a compromised way.

In ILAMP (https://tools.ietf.org/html/draft-herbert-ila-ilamp-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dherbert-2Dila-2Dilamp-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=ZuWBLVzaamz8AnvsRNdHoMiV9gskJSpDdZj5s3HGtPA&s=QU0hDuO1SK98mkjSZpPpNiJtNlg02UEcDpJakusxv60&e=>) secure redirects are defined to be the primary means of populating a cache. On a cache miss, a packet is forwarded into the network and routing should forward the packet to an ILA router that contains the complete set of mappings for the associated shard. The router performs the transformation and can send a redirect back to the caching node. The redirect can be cached so that subsequent packets take a direct route and avoid the trianglular routing. Redirects must be secure so that they cannot be spoofed, so for that reason (and some others) the protocol is over TCP. The mapping cache is only an optimization and packets are never dropped or queued for pending cache resolution. If the cache weren't present, communications would still be viable but sub-optimal; that characteristic establishes a bound for the worst case DOS attack.

Any thoughs on this approach?

Hi Lorenzo,

Thanks for the feedback!

The obvious ones would seem:

  *   Will the working set of cache mappins fit in whatever memory is available in, say, a large peering router?
The cache needs to be sized to fit the working set. Please look at the reference topology of section N. The intent is that caches would not be used at edge or peer routers, ILA router are used there which shard the mapping database across some number of  nodes. Mapping caches are at ILA-Ns which are deployed deeper in the network towards the end hosts (like toward gNB). There are more of these than ILA-Rs, however they are serve a small set of users and would be implemented on lower end devices. The purpose of the cache is to optimize latency and throughput of performance critical intra-network communications (Ue to UE, UE to application server in network).


  *   Remember that memory that is capable of sustaining routing lookups at tens of gigabits per second is extremely expensive.
  *   How do you defend against state exhaustion attacks whereby a large number of spoofed sources send packets to nonexistent destinations?
No cache state is created for nonexistent destinations.


  *   How much bandwidth will be used for the redirects? How much CPU time will be used to process them?
  *   How many servers are needed to store
Suggest gaming this out for a large mobile operator with, say, 100M clients, 100 Internet connection points and 10T of traffic.

I did an analysis of ILA scalability for a couple of scenarios (see attached), For the 100M UEs, the number of ILA routers came out to 530.

Tom