Re: [5gangip] BOF Description

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: crowcroft@gmail.com [mailto:crowcroft@gmail.com] On Behalf Of Jon Crowcroft
Sent: Sunday, February 04, 2018 12:51 PM
To: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
Cc: Tom Herbert <tom@herbertland.com>; Lorenzo Colitti <lorenzo@google.com>; 5GANGIP <5gangip@ietf.org>; Behcet Sarikaya <sarikaya@ieee.org>; Dirk.von-Hugo@telekom.de
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 <Peter.AshwoodSmith@huawei.com<mailto:Peter.AshwoodSmith@huawei.com>> 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:5gangip-bounces@ietf.org<mailto:5gangip-bounces@ietf.org>] On Behalf Of Tom Herbert
Sent: Friday, February 02, 2018 11:49 AM
To: Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>
Cc: 5GANGIP <5gangip@ietf.org<mailto:5gangip@ietf.org>>; Behcet Sarikaya <sarikaya@ieee.org<mailto:sarikaya@ieee.org>>; Dirk.von-Hugo@telekom.de<mailto:Dirk.von-Hugo@telekom.de>
Subject: Re: [5gangip] BOF Description

On Thu, Feb 1, 2018 at 9:56 PM, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>> wrote:
On Fri, Feb 2, 2018 at 4:34 AM, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> 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
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip