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

[Tom Herbert <[e-mail]>]

On Wed, May 30, 2018 at 5:38 PM, FIGURELLE, TERRY F <[e-mail]> wrote:
> 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.
>
Terry,

530 would be the number of devices not locations. They can be
co-located. That number is based one some back of the envelope
calculations assuming memory and bandwidth. I believe an ILA-R would
contain roughly the same amount of state as an anchor device in LTE
would.

In order to service critical low latency applications like those that
would benefit from the 1ms latency target in 5G, proximity and number
of hops become relevant. For 1ms RTT latency the devices must be
within 93 miles of each just based on speed of light alone. Device
processing reduces the maximum distance even more. The result is that
the application servers need to be pushed far to the edge and a direct
path between the client and server is needed for latency. This implies
both geographic proximity as well as minimizing number of hops which
is also desirable for increasing reliability, so MEC servers are
deployed in central office, or even cell towers or RSUs to be close to
the user. This is a motivation for anchorless routing that is in
identifier/locator proposals. For ILA, the in intent is that critical
low latency communications would have a direct path from ILA-N to
ILA-N or ILA-N to ILA-H-- where ILA-H are the end servers themselves.

Tom

>
>
> 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]> wrote:
>
> On Tue, Feb 6, 2018 at 12:37 AM, Tom Herbert <[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) 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
>
>
>
>