Re: [5gangip] BOF Description

[Lorenzo Colitti <[e-mail]>]

On a 10Gbps interface, 100ms means buffering 125 MB of packets, and 125MB
of the type of memory that's fast enough to keep a 10Gbps interface running
is prohibitively expensive. Your cache hit rate needs to be awfully high
for that to work without breaking the bank. Additionally, it creates a huge
DOS vector where anyone on the Internet can mount a state exhaustion attack
on the mapping cache, forcing the routers to swap out the entries of
legitimate customers, who would then experience substantial latency
increases, jitter, and packet loss. Finally, it's a good bet that the
routers that are close to popular web site destinations (e.g., the Android
and Apple push connection servers, the whatsapp servers...) will need to
have a working set of tens of millions of entries, and would thus be
permanently in a state of churn.

On Tue, Feb 6, 2018 at 12:12 AM, AshwoodsmithPeter <
[e-mail]> wrote:

> Hey Jon, Yes, that figure shows nicely the very linear behavior at scale,
> nearly flat at a few hundred milliseconds (although its likely a log).
>
>
>
> For example with most DHTs - Say 8,000 servers spread around a country and
> log2(8,000) messages required (worst case) to find the proper server i.e.
> 13 messages (each message reduces the search by ½). So your upper bound
> search time would be 13*Xms per hop. So getting to 100ms requires that each
> hop take no more than 8ms which includes time of flight and processing. If
> a server can store a million entries , the entire mapping system can deal
> with 8 billion entries, and likely much more. Obviously you can cache
> things and do even better but you need to keep the cache refreshed and in
> the end it comes down  to a O(log2(N))) in the worst case.
>
>
>
> If all of the servers are in SP clouds with high priority QOS and low
> latency between SP clouds it would seem quite doable, at least in the 100ms
> range which is adequate for 90% of traffic. That nicely frees up resources
> for the sub 50ms stuff that needs a make before break anchor type solution.
>
>
>
> Peter
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of *Jon
> Crowcroft
> *Sent:* Sunday, February 04, 2018 12:51 PM
> *To:* AshwoodsmithPeter <[e-mail]>
> *Cc:* Tom Herbert <[e-mail]>; Lorenzo Colitti <
> [e-mail]>; 5GANGIP <[e-mail]>; Behcet Sarikaya <
> [e-mail]>; [e-mail]
>
> *Subject:* Re: [5gangip] BOF Description
>
>
>
> if you want consistency in replicated map servers, you could consider
> paxos made switchy - performance see fig 2 in this 3yr old paper:)
>
> http://www.inf.usi.ch/faculty/soule/sosr15.pdf
>
>
>
> On Fri, Feb 2, 2018 at 6:59 PM, AshwoodsmithPeter <
> [e-mail]> wrote:
>
> Large scale distributed mapping systems have been the subject of extensive
> research and work for at least 20 years (Chord etc.)
>
>
>
> Pretty much every large cloud application uses a distributed mapping
> system, some of them at the 100’s of millions of entries scale
> (Skype/WeChat/etc..) with world wide distribution. Several of their API’s
> are publicly available and you can easily try them for yourself to see the
> performance.( In general they deliver O(Log(N)) read, O(Log(N) ) messages
> write where N is the number of nodes over which the keys/values are
> distributed.)
>
>
>
> We actually tried this with our simple ID/LOC split LTE prototype by
> forcing each move to require a query of Google or Azure’s noSQL DB. We saw
> numbers in the 100-300ms range for these world-wide general purpose mapping
> systems. It is not impossible to imagine that a custom built system for a
> single carrier with country wide scope and dedicated resources would return
> significantly better results i.e. 4-5ms * Log(N) + propagation delays..
>
>
>
> Arash gave demos of this a while ago and there are recorded versions of
> that demo on WebX if people are interested.
>
>
>
> I have been grumbling that the world needs a “world wide mapping system”
> for many years now. It would be amazing if the IETF could standardize such
> a thing and ISPs all over the world could put servers to use supporting it.
>
>
>
> Cheers,
>
>
>
> Peter
>
>
>
> *From:* 5gangip [mailto:[e-mail]] *On Behalf Of *Tom
> Herbert
> *Sent:* Friday, February 02, 2018 11:49 AM
> *To:* Lorenzo Colitti <[e-mail]>
> *Cc:* 5GANGIP <[e-mail]>; Behcet Sarikaya <[e-mail]>;
> [e-mail]
> *Subject:* Re: [5gangip] BOF Description
>
>
>
>
>
>
>
> On Thu, Feb 1, 2018 at 9:56 PM, Lorenzo Colitti <[e-mail]>
> wrote:
>
> On Fri, Feb 2, 2018 at 4:34 AM, Behcet Sarikaya <[e-mail]>
> wrote:
>
> ·         Most Id-Loc split solutions need mapping server to look up
> efficiently for changes in locators of Identities. Scalability and
> performance of such mapping systems is not in scope.
>
> This really doesn't make sense. The way I see it, the main downside of
> ID-locator split solutions *is precisely* the fact that the mapping system
> is hard to scale. Any scheme or solution that doesn't also address this
> scaling problem is undeployable at scale and therefore not useful to
> discuss in the context of any real deployment.
>
>
>
> IMO, building a scalable and secure mapping system is probably the most
> tangible problem raised on this list. It's an emerging problem common to
> most identifier-locator protocols, network virtualization, and other use
> cases. Scalability is just one problem, there's also questions of leverging
> database technology, security and access control, caching data.  It could
> be a topic in its own right. I believe this was part of the intent in IDEAS
> but that may have been sidetrack by trying to assert identity as a major
> element of identifier/locator split.
>
>
>
> Tom
>
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>
>