Subject: [5gangip] BOF Description

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 1 Feb 2018 13:34:52 -0600

Hi all,

Here is the first version of the BOF description hopefully to be submitted
by tomorrow.
Please post comments/corrections to the list.

Regards,
Dirk & Behcet

   - • BOF's full name and acronym in brackets
   - IP Issues and Associated Gaps in Fifth Generation Wireless Networks
   -         (or: Issues and Gaps in Next Generation Converged IP Networks)
   [atick]
   - AREA under which Working Group or BOF appears
   - INT area
   - Chair(s) Name(s) and e-mail address(es)
   -         Behcet and Dirk (?) – t.b.c.
   - Agenda

·         Introduction to problem space – new network concepts require new
approaches (Chairs)

·         Issues with and specifics of current tunneling approaches as e.g.
3GPP GTP (Alex)

·         Proposed approach in terms of basic framework for flexible path
optimisation based on an extensible ID-Loc split protocol, e.g. ILNP
(Saleem)

·         Essential features to be addressed in future steps (Arash)

·         Proposed charter and milestones (chairs)

·         Q&A

·         Discussion

   - Full Description of BOF

·         Within future converged (wireless/wireline) communication systems
based on IPv6 which attempt to provide revolutionary new network concepts
(e.g. slicing) traditional approaches as Tunneling is still foreseen. Such
protocols may create too much overhead and hide important information
required for service-specific handling of data packet flows. Not only may
the tunnel overhead exceed the payload by orders of magnitude (e.g. for
some IoT messages) and result in MTU size issues and packet fragmentation
but also create signaling related to tunnel management such as
establishment, maintenance, and tear down, as well as tracking the state of
the tunnels in all layers (see e.g. [
https://tools.ietf.org/html/draft-ietf-intarea-tunnels]).

·         Currently discussed Id-Loc split approach (e.g. LISP, ILNP, ILA)
could be advantageous here especially with regard to simplifying routing by
keeping Identity stable during a session/flow, allowing integration of
multiple heterogeneous access technologies, being flexible to add
functionalities only on-demand, and intrinsically supporting mobility. Such
approaches  also well fit to work in virtual environments (SDN/NFV) and
react dynamically to changes of locations of processing resources (e.g. for
virtual machines executing VNFs).

·         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.

·         Existing Id-Loc split approaches require extensions to allow for
optimization of the routing path which could be derived from the mapping
records if properly constructed and distributed.

·         As a first step, atick will address an analysis of the features
the alternative protocol has to provide (e.g. what currently is built-in in
GTP).

·         Specification of the complete protocol enhancements to support
e.g. charging and policy enforcement, but also interoperability and
migration from existing network structures will be in scope of future work
items. Also the ultimate evaluation of a comparison to GTP in terms of
performance and effort etc. can be achieved once the alternative protocol
framework is fully specified.

   - CONFLICTS you wish to avoid, please be as specific as possible:
   INTarea, dmm, lisp, 6man, nvo3, sfc
   - Expected Attendance (figures from the previous IETF meeting are
   included in the message that is sent when scheduling opens):100
   - Special requests:non
   - Number of sessions:1
   - Length of sessions:
      - 1 hour

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 11:52:53 -0800

Has the group decided on a solution? Why did you single out ILNP below? You should remove it or include all proposals that have been discussed so far on this list.

Dino

> On Feb 1, 2018, at 11:34 AM, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi all,
> 
> Here is the first version of the BOF description hopefully to be submitted by tomorrow.
> 	• •	BOF's full name and acronym in brackets
> 	• IP Issues and Associated Gaps in Fifth Generation Wireless Networks 
> 	•         (or: Issues and Gaps in Next Generation Converged IP Networks) [atick]
> 	• AREA under which Working Group or BOF appears
> 	• INT area
> 	• Chair(s) Name(s) and e-mail address(es)
> 	•         Behcet and Dirk (?) – t.b.c.
> 	• Agenda
> 
> ·         Introduction to problem space – new network concepts require new approaches (Chairs)
> 
> ·         Issues with and specifics of current tunneling approaches as e.g. 3GPP GTP (Alex)
> 
> ·         Proposed approach in terms of basic framework for flexible path optimisation based on an extensible ID-Loc split protocol, e.g. ILNP (Saleem)
> 
> 	• Full Description of BOF
> ·         Within future converged (wireless/wireline) communication systems based on IPv6 which attempt to provide revolutionary new network concepts (e.g. slicing) traditional approaches as Tunneling is still foreseen. Such protocols may create too much overhead and hide important information required for service-specific handling of data packet flows. Not only may the tunnel overhead exceed the payload by orders of magnitude (e.g. for some IoT messages) and result in MTU size issues and packet fragmentation but also create signaling related to tunnel management such as establishment, maintenance, and tear down, as well as tracking the state of the tunnels in all layers (see e.g. [https://tools.ietf.org/html/draft-ietf-intarea-tunnels]).
> 
> ·         Currently discussed Id-Loc split approach (e.g. LISP, ILNP, ILA) could be advantageous here especially with regard to simplifying routing by keeping Identity stable during a session/flow, allowing integration of multiple heterogeneous access technologies, being flexible to add functionalities only on-demand, and intrinsically supporting mobility. Such approaches  also well fit to work in virtual environments (SDN/NFV) and react dynamically to changes of locations of processing resources (e.g. for virtual machines executing VNFs).
> 
> ·         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.
> 
> ·         Existing Id-Loc split approaches require extensions to allow for optimization of the routing path which could be derived from the mapping records if properly constructed and distributed.
> 
> ·         As a first step, atick will address an analysis of the features the alternative protocol has to provide (e.g. what currently is built-in in GTP).
> 
> ·         Specification of the complete protocol enhancements to support e.g. charging and policy enforcement, but also interoperability and migration from existing network structures will be in scope of future work items. Also the ultimate evaluation of a comparison to GTP in terms of performance and effort etc. can be achieved once the alternative protocol framework is fully specified.
> 
> 
> 	• CONFLICTS you wish to avoid, please be as specific as possible: INTarea, dmm, lisp, 6man, nvo3, sfc 
> 	• Expected Attendance (figures from the previous IETF meeting are included in the message that is sent when scheduling opens):100
> 	• Special requests:non
> 	• Number of sessions:1
> 	• Length of sessions:
> 		• 1 hour
> 
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Saleem Bhatti <[email-masked]>
Date: Thu, 1 Feb 2018 20:41:41 +0000

> On 01 Feb 2018, at 19:52, Dino Farinacci <[email-masked]> wrote:
> 

Agreed - it is too early to be able to make a decision.

I do not believe the problem-space is yet well-defined, let alone the solution-space.

Cheers,
--/Saleem

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 1 Feb 2018 14:59:10 -0600

On Thu, Feb 1, 2018 at 2:41 PM, Saleem Bhatti <[email-masked]>
wrote:

> > Has the group decided on a solution? Why did you single out ILNP below?
> You should remove it or include all proposals that have been discussed so
> far on this list.
>
I thought the problem space was defined in the BOF text, if not then make
specific comments we will seriously consider adding /changing.

Of course the solution is not defined and that is the reason d'etre of our
BOF proposal.
We selected ILNP as a tool because our AD's feedback was very clear, decide
on one thing not more.
We are not singling out the others, but you have to decide one early to
concentrate on first, be successful and then consider the others.

I hope this clarifies.
Maybe tomorrow Dirk can add more.

Regards,
Behcet

Cheers,
> >> ·         Proposed approach in terms of basic framework for flexible
> path optimisation based on an extensible ID-Loc split protocol, e.g. ILNP
> (Saleem)
> >>
> >> ·         Within future converged (wireless/wireline) communication
> systems based on IPv6 which attempt to provide revolutionary new network
> concepts (e.g. slicing) traditional approaches as Tunneling is still
> foreseen. Such protocols may create too much overhead and hide important
> information required for service-specific handling of data packet flows.
> Not only may the tunnel overhead exceed the payload by orders of magnitude
> (e.g. for some IoT messages) and result in MTU size issues and packet
> fragmentation but also create signaling related to tunnel management such
> as establishment, maintenance, and tear down, as well as tracking the state
> of the tunnels in all layers (see e.g. [https://tools.ietf.org/html/
> draft-ietf-intarea-tunnels]).
> >>
> >> ·         Currently discussed Id-Loc split approach (e.g. LISP, ILNP,
> ILA) could be advantageous here especially with regard to simplifying
> routing by keeping Identity stable during a session/flow, allowing
> integration of multiple heterogeneous access technologies, being flexible
> to add functionalities only on-demand, and intrinsically supporting
> mobility. Such approaches  also well fit to work in virtual environments
> (SDN/NFV) and react dynamically to changes of locations of processing
> resources (e.g. for virtual machines executing VNFs).
> >>
> >> ·         Existing Id-Loc split approaches require extensions to allow
> for optimization of the routing path which could be derived from the
> mapping records if properly constructed and distributed.
> >>
> >> ·         As a first step, atick will address an analysis of the
> features the alternative protocol has to provide (e.g. what currently is
> built-in in GTP).
> >>
> >> ·         Specification of the complete protocol enhancements to
> support e.g. charging and policy enforcement, but also interoperability and
> >>      • Expected Attendance (figures from the previous IETF meeting are

---

From: <[email-masked]>
Date: Thu, 1 Feb 2018 22:47:10 +0000

Whilst I understand the desire not to boil the ocean, I see a very similar issue in this BoF to what has happened in NetSlices.

I thought that the goal of 5gangip was to see what the protocols and architecture should look like in the 5G Next Generation core network.   We have an outline architecture for the 5G Next Gen core – we even have some proposed protocols but these are mostly based on today’s network – not Next Gen.

We have a problem.  If we narrow the scope too much, then we end up making this one protocol solution and we will miss the opportunity to define anything new into 5G.

On the other hand, we don’t know what that “new” should be because it is still in active research and definition at 3GPP.

On the third hand (three hands – nice) if we don’t narrow the scope, we are in danger of never actually getting the WG off the ground.

I see the same issue happening in NetSlices.

Yes, we could define GTP in IETF, but that is NOT a Next Generation protocol as is the title of the group.   I suggest we leave current N3 definition for the first phase of 5G NG core as that is pretty-much a given.

Likewise, N6 is, for now, IP (v4/v6 doesn’t matter – these are today’s protocols).

So if we look at the entire user-plane, we could consider alternate protocols for N3, N9 and N6 but we would have to do that in conjunction with considering the programming model control plane.  N4 is defined but only again in terms of today’s network.  When you read 29.244, it becomes quickly apparent that most aspects of 5G programmability have been left for the future.

I think the goal of the BoF should be to:

  1.  Define the problem space
  2.  Try to consolidate research work in this space
  3.  Liaise with 3GPP into areas which they have not yet started to consider for Next Gen core (e.g. potential new N3 and N9 protocols, expansion of N4, etc).

I don’t see that we are ready to pitch any kind of solution as-yet.

More controversially, given the lack of maturity in 5G technology, would this (and potentially NetSlices and possibly IDEAS) be better suited to an IRTF group or an IAB study area?   That way we could study the whole problem space and generate WGs as-needed to solve specific problems.

David

From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: 01 February 2018 20:59
To: Saleem Bhatti <[email-masked]>
Cc: 5GANGIP <[email-masked]>; Dino Farinacci <[email-masked]>; [email-masked]
Subject: Re: [5gangip] BOF Description

On Thu, Feb 1, 2018 at 2:41 PM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

> On 01 Feb 2018, at 19:52, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:
>

I thought the problem space was defined in the BOF text, if not then make specific comments we will seriously consider adding /changing.

Of course the solution is not defined and that is the reason d'etre of our BOF proposal.
We selected ILNP as a tool because our AD's feedback was very clear, decide on one thing not more.
We are not singling out the others, but you have to decide one early to concentrate on first, be successful and then consider the others.

I hope this clarifies.

Regards,
Behcet

Cheers,
--/Saleem

>
> Dino
>
>> On Feb 1, 2018, at 11:34 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Hi all,
>>
>> ·         Within future converged (wireless/wireline) communication systems based on IPv6 which attempt to provide revolutionary new network concepts (e.g. slicing) traditional approaches as Tunneling is still foreseen. Such protocols may create too much overhead and hide important information required for service-specific handling of data packet flows. Not only may the tunnel overhead exceed the payload by orders of magnitude (e.g. for some IoT messages) and result in MTU size issues and packet fragmentation but also create signaling related to tunnel management such as establishment, maintenance, and tear down, as well as tracking the state of the tunnels in all layers (see e.g. [https://tools.ietf.org/html/draft-ietf-intarea-tunnels]<https://tools.ietf.org/html/draft-ietf-intarea-tunnels%5d>).
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Feb 2018 14:56:03 +0900

> 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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 2 Feb 2018 08:02:27 +0100

Le 02/02/2018 à 06:56, Lorenzo Colitti a écrit :
> On Fri, Feb 2, 2018 at 4:34 AM, Behcet Sarikaya <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     ·Most Id-Loc split solutions need mapping server to look up
> 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.

I think it depends on the kind of needed deployment.

I think id-loc split methods dont scale to the size of the Internet, 
because of necessity of numerous mapping registration bases, but do 
scale to the size of a cellular operator.

REversely, the tunnelling methods used by cellular operator (GTP etc) do 
scale to the size of the Internet but generate inefficiencies when used 
in the small size of a cellular operator (too many encap layers, too 
many cycles to maintain tunnels compared RIB searches, too long paths, etc).

One should really think about id-loc in the context of existing problems.

Let us take VoLTE: presumably higher audio quality with Voice-over-IP 
compared with 3G voice calls.  But is that quality maintained when VoLTE 
is with triangular paths, i.e. while roaming?  I guess not.  Will id-loc 
split maintain audio quality on VoLTE while roaming: I think so.

Alex

---

From: <[email-masked]>
Date: Fri, 2 Feb 2018 08:19:32 +0000

Alex

Apologies for top-down reply,  but I wanted to reply immediately on the VoLTE question.

You have to be very careful when stating “improved voice quality in VoIP” - the improvement is due to the codec, not IP.   News interviews on the radio have been done for years over high-quality codecs using ISDN and the quality has been excellent with virtually zero drop-outs.   You only need to listen to an interview on the radio today where a down-the-line package is delivered over IP and the quality is often very variable.  One of the best quality phones I ever owned was a Hagenuk ISDN system which used 2 bonded B channels to another Hagenuk.   I can tell you now that Skype is never as good to a musicians ear!

The issue is the inability to reserve the required profile of traffic through the Internet (at least dynamically on a per application basis and across peering points).

In LTE, the profile set by the PCRF does several things:

1) it allocates a bearer with specific radio characteristics
2) it marks packets with appropriate quality markings.
3) it can steer packers to a particular SGi interface

So within an operators domain it is possible to allocate exactly the resources required against the codec.  This is the same as a number of VoIP vendors such as Cisco do with their IP PBX solutions (research Call Admission Control).

IMS was designed to do a very similar thing and within the operator’s domain, does it very well.  There have been proposals in the past to extend IMS-like capabilities within wired networks.  Never gone anywhere mostly because in wireline we’ve been able to throw bandwidth at the problem and the whole thorny question of traffic profiling becomes quite political in some geographies.

PCRF and LTE have 9 (I think?) levels of QCI for different traffic profiles - today we use 2; best efforts and Voice.

There is also great need in cellular systems to manage bandwidth at a microscopic level because bandwith=spectrum=£bn.

The key is to have policy control of the transport network at all levels.

In terms of VoLTE roaming, several operators have this in place today and LTE caters for this.

However, the issue is that trying to allocate IP transport bandwidth between networks which is treated correctly is difficult and becomes more difficult where the codec charactistics vary.  Several solutions exist to this: nail-up what you think will be enough bandwidth at an appropriate packet treatment (this is voice, so low-latency queuing with minimal drop) or break out locally.   Neither are ideal.

Also, the 3gpp designs are quite operator-centric so whilst you could envisage a solution where, for example, BBC iPlayer was able to run over a higher-quality QCI based on a user paying for a better service (user could be either end), it isn’t often done.

I don’t see how ID/Loc addresses this - the fundamental issue is that as a user, I have no way of expressing the packet treatment End-to-End I require and having that delivered against an SLA as I can within an LTE/IMS Network.   To me, a Next Gen protocol would allow me to state the quality of service I want from source to destination and have that built across all elements in the service delivery path.

(BTW, 3G voice is circuit-switched.)

David

Sent from my iPhone
_____________________________
From: Alexandre Petrescu <[email-masked]>
Sent: Friday, February 2, 2018 7:02 am
Subject: Re: [5gangip] BOF Description
To: <[email-masked]>

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Feb 2018 22:25:47 +0900

On Fri, Feb 2, 2018 at 4:02 PM, Alexandre Petrescu <
[email-masked]> wrote:

> because of necessity of numerous mapping registration bases, but do scale
> to the size of a cellular operator.
>

Do they? Do the math.

Large cellular operators have many tens of millions of customers. Without
tunneling, each of these requires one entry in the routing table (two if
the network is dual-stack). That means that if a packet comes in from the
Internet, without aggregation or tunneling, something close to the ingress
point needs to look at a table with tens of millions of entries.

Routers these days can probably store about 1M routes in their FIB. We're
talking about 10x-100x that. I don't think some handwavy statement around
"a mapping service that's out of scope" is going to be convincing.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 2 Feb 2018 09:18:36 -0600

Hi Lorenzo,

> "a mapping service that's out of scope" is going to be convincing.
Good point.
We had  left it out of scope because we want to reduce what we propose to
do as much as possible in the first step.
We will modify that sentence before submitting.

Regards,
Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 2 Feb 2018 09:31:11 -0600

Folks,

Presenter names in BOF description are tentative.
If the BOF is accepted we we wiil ask from the list volunteers to do the
presentations.

Regards,
Behcet

---

From: <[email-masked]>
Date: Fri, 2 Feb 2018 16:34:46 +0000

Dear all,
based on your valued comments we submitted the revised BoF request ATICK and keep you informed of the outcome.
Thanks a lot for continuing support!
Best Regards – also on behalf of Behcet
Dirk
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Freitag, 2. Februar 2018 16:31
To: Saleem Bhatti <[email-masked]>
Cc: Dino Farinacci <[email-masked]>; 5GANGIP <[email-masked]>; von Hugo, Dirk <[email-masked]>
Subject: Re: [5gangip] BOF Description

Folks,

Presenter names in BOF description are tentative.
If the BOF is accepted we we wiil ask from the list volunteers to do the presentations.

Regards,
Behcet

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 Feb 2018 08:48:31 -0800

On Thu, Feb 1, 2018 at 9:56 PM, Lorenzo Colitti <[email-masked]> wrote:

> 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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 2 Feb 2018 18:59:24 +0000

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:[email-masked]] On Behalf Of Tom Herbert
Sent: Friday, February 02, 2018 11:49 AM
To: Lorenzo Colitti <[email-masked]>
Cc: 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>; [email-masked]
Subject: Re: [5gangip] BOF Description

On Thu, Feb 1, 2018 at 9:56 PM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Feb 2, 2018 at 4:34 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> 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

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 Feb 2018 11:20:49 -0800

On Fri, Feb 2, 2018 at 10:59 AM, AshwoodsmithPeter <
[email-masked]> 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.
>
>
>
Peter,

Overcoming the privacy, security, policy, and legal ramifications of
defining a "world wide mapping system" for identifer-locator split is
likely insurmountable. Scoping a mapping system to be contained a closed
and trusted network that can provide contractual guarantees of security and
privacy to users of the network might be more tenable. Scaling is still an
issue because such networks can be very large.

Tom

Cheers,
>
>
>
> Peter
>
>
>
> *From:* 5gangip [mailto:[email-masked]] *On Behalf Of *Tom
> Herbert
> *Sent:* Friday, February 02, 2018 11:49 AM
> *To:* Lorenzo Colitti <[email-masked]>
> *Cc:* 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>;
> [email-masked]
> *Subject:* Re: [5gangip] BOF Description
>
>
>
>
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Feb 2018 10:37:31 -0800

The question to be answered is if all 10 million need to be stored in one place at the same time. 

Lorenzo, do you think the DNS is scaling? And if the mapping system is designed roughly the same way, could it scale?

Also, the other point you made about third-party dependency, is a another question about push versus pull style of operation. 

I just posted a draft that arguably proposes a push kind of distribution. Mostly for the benefit of decentralization. You can find it in draft-farinacci-lisp-decent-00. 

Trade offs,
Dino

> On Feb 2, 2018, at 7:18 AM, Behcet Sarikaya <[email-masked]> wrote:
> 
> Hi Lorenzo,
> 
>>> On Fri, Feb 2, 2018 at 4:02 PM, Alexandre Petrescu <[email-masked]> wrote:
>>> I think id-loc split methods dont scale to the size of the Internet, because of necessity of numerous mapping registration bases, but do scale to the size of a cellular operator.
>> 
>> Do they? Do the math.
>> 
>> Large cellular operators have many tens of millions of customers. Without tunneling, each of these requires one entry in the routing table (two if the network is dual-stack). That means that if a packet comes in from the Internet, without aggregation or tunneling, something close to the ingress point needs to look at a table with tens of millions of entries.
>> 
>> Routers these days can probably store about 1M routes in their FIB. We're talking about 10x-100x that. I don't think some handwavy statement around "a mapping service that's out of scope" is going to be convincing.
>> 
> 
> Good point.
> We had  left it out of scope because we want to reduce what we propose to do as much as possible in the first step.

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 2 Feb 2018 10:38:58 -0800

> 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.

Agree. And my assessment as well. 

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 4 Feb 2018 18:40:16 +0100

Le 02/02/2018 à 14:25, Lorenzo Colitti a écrit :
> On Fri, Feb 2, 2018 at 4:02 PM, Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Large cellular operators have many tens of millions of customers. 
> Without tunneling, each of these requires one entry in the routing table 
> (two if the network is dual-stack).

Agreed.

But, in more detail, how many parameters for each entry?

Because, with tunelling too, each of these requires one entry in a 
tunnel table.

A tunnel has at least 4 IP parameters in one machine, and often a 5th 
and more (the GRE's key, the GTP's "Tunnel ID", and potentially many 
others).  Whereas nn entry in the routing table has, mainly, solely the 
prefix to compare against the dst of a received packet.

BEsides, the scalability I refer to, is not that of memory requirements 
in one computer (PGW) but that of total mem reqs on all impacted routers.

It is possible to use 'route updates' and modify all router tables upon 
mobility, inside an operator network.  The number of routers is limited. 
  It scales.  But it is not possible to use 'route updates' across the 
Internet because the number of impacted routers upon a mobility event is 
very large.  _There_ there is a need of tunnels, not inside an operator 
network.

A 'mapping system' is a little bit like 'route updates', except they 
further reduce the number of impacted routers to just these Databases.

> That means that if a packet comes in 
> from the Internet, without aggregation or tunneling, something close to 
> the ingress point needs to look at a table with tens of millions of entries.

Yes, I understand that.

> Routers these days can probably store about 1M routes in their FIB. 
> We're talking about 10x-100x that. I don't think some handwavy statement 
> around "a mapping service that's out of scope" is going to be convincing.

I agree.

There would be a need to explain sizes, rather than just hand waving.

To me, it is clear that using tunnels in a operator network is 
unnecessary.  A mapping system would clearly provide advantages inside 
there.

Alex

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 4 Feb 2018 17:51:26 +0000

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

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 5 Feb 2018 15:12:58 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Crowcroft
Sent: Sunday, February 04, 2018 12:51 PM
To: AshwoodsmithPeter <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Lorenzo Colitti <[email-masked]>; 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Large scale distributed mapping systems have been the subject of extensive research and work for at least 20 years (Chord etc.)

Cheers,

Peter

From: 5gangip [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tom Herbert
Sent: Friday, February 02, 2018 11:49 AM
To: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: 5GANGIP <[email-masked]<mailto:[email-masked]>>; Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] BOF Description

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Feb 2018 09:35:54 +0900

LISP-DDT is log(n) as well and probably doesn’t require the trust model among nodes that DHT does. 

Dino

> On Feb 6, 2018, at 12:12 AM, AshwoodsmithPeter <[email-masked]> wrote:
> 
> On Fri, Feb 2, 2018 at 6:59 PM, AshwoodsmithPeter <[email-masked]> wrote:
> On Fri, Feb 2, 2018 at 4:34 AM, Behcet Sarikaya <[email-masked]> wrote:

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Feb 2018 14:41:32 +0900

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 <
[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Jon
> Crowcroft
> *Sent:* Sunday, February 04, 2018 12:51 PM
> *To:* AshwoodsmithPeter <[email-masked]>
> *Cc:* Tom Herbert <[email-masked]>; Lorenzo Colitti <
> [email-masked]>; 5GANGIP <[email-masked]>; Behcet Sarikaya <
> [email-masked]>; [email-masked]
>
> if you want consistency in replicated map servers, you could consider
> paxos made switchy - performance see fig 2 in this 3yr old paper:)
>

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 6 Feb 2018 09:48:32 +0000

Lorenzo;

On 02 Feb 2018, at 05:56, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

Not all Id/Loc systems are the same. Not all need to map Id values to Locators.

ILNP does not map Id values to Locator values.

ILNP uses DNS lookups (as for IP today) so that DNS names map to an Id/Loc pair. Then, nodes use direct signalling with Locator Updates as they move, and update DNS with new Locator values.

Updating DNS securely is possible today with, but deployed DNS engineering is not optimised for write operations. At the current time, at least, there is a significant performance hit with using DNS in this way.

So, overall, for ILNP, the scaling issues with Locator updates are related to the performance of secure DNS write operations.

Cheers,
--/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 6 Feb 2018 09:55:11 +0000

On 02 Feb 2018, at 18:59, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>> wrote:

DNS?

DNS secure write performance is relatively poor (at least with the lab set-ups my student has been trying), but I suspect that is because optimising DNS secure write performance has not received much engineering attention, as it has not been something that has been widely used or seen to be widely needed(?).

Cheers,
--/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Feb 2018 22:10:22 +0900

And DNS doesn’t have pubsub. So that means caching DNS entries need to poll for changes. That will make handoffs as fast as the polling interval. 

Dino

> On Feb 6, 2018, at 6:48 PM, Saleem Bhatti <[email-masked]> wrote:
> 
> Lorenzo;
> 
>> On 02 Feb 2018, at 05:56, Lorenzo Colitti <[email-masked]> wrote:
>>

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 6 Feb 2018 14:17:52 +0000

On 06 Feb 2018, at 13:10, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

Why not just set a low TTL value for the DNS RRs (e.g. 1s or 0s)?

Cheers,
--/Saleem

Dino

On Feb 6, 2018, at 6:48 PM, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

Lorenzo;

Cheers,
--/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Feb 2018 23:21:28 +0900

> Why not just set a low TTL value for the DNS RRs (e.g. 1s or 0s)?

Then that increases request load when there are no locator changes. 

Dino

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 6 Feb 2018 14:29:45 +0000

Dino;

> On 06 Feb 2018, at 14:21, Dino Farinacci <[email-masked]> wrote:
> 
>> 

a) Only need to change / set low TTL for DNS RRs that move.

b) Even if that is all the nodes, then the additional load in DNS is not significant - please see:

    Reducing DNS Caching.
    14th IEEE Global Internet Symposium (GI2011), Shanghai, China. 15 April 2011.
    http://dx.doi.org/10.1109/INFCOMW.2011.5928919
    https://goo.gl/z31vAF    

Cheers,
--/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Feb 2018 23:43:25 +0900

> a) Only need to change / set low TTL for DNS RRs that move.

My point is if you set them low and even if they move, when they are standing still, you have unnecessary request load. 

>    http://dx.doi.org/10.1109/INFCOMW.2011.5928919

Well aware. But the load is high if you do it for 100 million mobiles. 

LISP has the same issue but with SMRs and pubsub we can trade off state rather than use TTLs. But the spec documents all. 

Dino

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 6 Feb 2018 14:49:58 +0000

Dino;

> On 06 Feb 2018, at 14:43, Dino Farinacci <[email-masked]> wrote:
> 
>> 

Yes, I see ... but that load is not significant (see the paper for details - zero TTL for several hundred hosts for a week, with measurements).

Also, for a phone, it will be dependent only on how many incoming call requests you might get. I am guessing that it will be low, e.g. 1 request per several minutes (as a mean), even for a busy phone/end-system.

Cheers,
--/Saleem

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 6 Feb 2018 15:07:35 +0000

Unfortunately DNS is optimized for read. Essentially it gets you O(1) read. The writes have to be O(N) to do that.

PubSub / DHT etc. are optimized for read & write and deliver O(Log(N)) both operations.  Its why they are almost exclusively used for OTT like Location/ID separation.

Peter

From: Saleem Bhatti [mailto:[email-masked]]
Sent: Tuesday, February 06, 2018 4:55 AM
To: AshwoodsmithPeter <[email-masked]>
Cc: Tom Herbert <[email-masked]>; Lorenzo Colitti <[email-masked]>; 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>; [email-masked]
Subject: Re: [5gangip] BOF Description

DNS?

Cheers,
--/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 6 Feb 2018 15:15:56 +0000

Peter;

On 06 Feb 2018, at 15:07, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>> wrote:

Unfortunately DNS is optimized for read.

Agreed.

Essentially it gets you O(1) read. The writes have to be O(N) to do that.

Perhaps I have not understood your comment, but there is only one DNS record to update when a node moves, as long as that record is not cached (see my previous email about setting TTL low), so that is O(1) also.

However, DNS server software does not seem to be optimised for secure write at the moment, and performance is low. However, I am pretty sure that if there was a demand for such a thing, the DNS server software providers would tweak the engineering as required to improve secure write performance. I do not have a feeling for what kind of peak performance they could achieve, but I am guessing they would approach database write speeds at least.

Agreed: pub-sub and DHT are also possible solutions.

Cheers,
--/Saleem

Peter

From: Saleem Bhatti [mailto:[email-masked]]
Sent: Tuesday, February 06, 2018 4:55 AM
To: AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>; Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] BOF Description

DNS?

Cheers,
--/Saleem

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 6 Feb 2018 15:17:19 +0000

True, but the interface which is changing is a wireless interface for a single UE so likely won’t be 10Gbps (not just yet ;)  .. also for most applications you can drop 100ms of packets and nothing horrible will happen. If you can’t tolerate it then yes you need a make before break anchor point solution, or a 50ms mapping system response.

As to the mapping servers, they don’t need to be accessible on the Internet since you don’t need to do the mapping on the UE. They need to be accessible within a SP network only and only between SP’s that trust each other.

Peter

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, February 06, 2018 12:42 AM
To: AshwoodsmithPeter <[email-masked]>
Cc: Jon Crowcroft <[email-masked]>; Tom Herbert <[email-masked]>; 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>; [email-masked]
Subject: Re: [5gangip] BOF Description

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 <[email-masked]<mailto:[email-masked]>> 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).

Peter

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jon Crowcroft
Sent: Sunday, February 04, 2018 12:51 PM
To: AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>; Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Cheers,

Peter

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 6 Feb 2018 09:32:24 -0600

Folks,

Thanks for this very enlightening discussion.
I am glad at this moment both sides understand each other much better and I
got the impression that there is some sort of consensus building which is
good for atick. We will elaborate this point more.

Regards,
Behcet

On Tue, Feb 6, 2018 at 9:17 AM, AshwoodsmithPeter <
[email-masked]> wrote:

> True, but the interface which is changing is a wireless interface for a
> single UE so likely won’t be 10Gbps (not just yet ;)  .. also for most
> applications you can drop 100ms of packets and nothing horrible will
> happen. If you can’t tolerate it then yes you need a make before break
> anchor point solution, or a 50ms mapping system response.
>
>
>
> As to the mapping servers, they don’t need to be accessible on the
> Internet since you don’t need to do the mapping on the UE. They need to be
> accessible within a SP network only and only between SP’s that trust each
> other.
>
>
>
> Peter
>
>
>
> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Tuesday, February 06, 2018 12:42 AM
> *Cc:* Jon Crowcroft <[email-masked]>; Tom Herbert <
> [email-masked]>; 5GANGIP <[email-masked]>; Behcet Sarikaya <

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 6 Feb 2018 15:57:25 +0000

Ø  Essentially it gets you O(1) read. The writes have to be O(N) to do that.

>Perhaps I have not understood your comment, but there is only one DNS record to update when a node moves, as long as that record is not cached (see my previous email about setting TTL low), so that…

Hey Saleem,

To scale a state distribution system you need N=1000’s of servers to spread the client’s read/write/query load. Any client can send a read/write/query to any server and ideally at huge scales the client load on servers should balance out.  I.e. each server handles #Users/#servers of the load. You can approach this several ways:

1-     A message to write arrives at an arbitrary server from a client, it then has to send a copy to all N other servers. That yields O(N) write messages and O(1) read messages. This is only good when there are vastly more read’s than writes.

2-     A message to write arrives at an arbitrary node, no copies are made, a read requires O(N) messages to find this on another server. This is only useful when there are vastly more writes than reads.

3-     A message to write arrives at an arbitrary server, log(N) messages are used to find the proper server for this key, a read can now arrive at any arbitrary server and again log(N) messages allow you to find the previous server with the key. This approach can also be balanced on the fly by moving the keys from server to adjacent server (in constant time remarkably), and likewise client balance can also be adjusted on the fly by simple redirection embedded in the client server protocol.

My point is that 3 is about the best you can do for both read/write while also spreading the client load. If you don’t care about spreading the client load or have a massive imbalance between reads and writes then there are better options (DNS/trees etc.) but I believe load spread, and even read/write performance is a requirement for a scalable mapping system for IDLOC and I suspect order analysis would show there is no theoretically better approach in terms of total messaging (at the limit).

Cheers,

Peter

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 6 Feb 2018 16:11:55 +0000

Peter;

I agree with your general description - architecturally, a DNS write is O(1), but that depends on the engineering for load sharing, as you describe below.

I would be very interested to hear how busy DNS servers are set-up for load-sharing and for dealing with writes, e.g. I wonder what dyn.com<http://dyn.com> do? Anyone on the list know?

Cheers,
--/Saleem

Hey Saleem,

Cheers,

Peter

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 6 Feb 2018 16:18:05 +0000

back in the day, we built this beast, just to see what it could take:
https://www.cl.cam.ac.uk/research/srg/netos/papers/2005-mainname-ccr.pdf

On Tue, Feb 6, 2018 at 4:11 PM, Saleem Bhatti <[email-masked]>
wrote:

> Peter;
>
> I agree with your general description - architecturally, a DNS write is
> O(1), but that depends on the engineering for load sharing, as you describe
> below.
>
> I would be very interested to hear how busy DNS servers are set-up for
> load-sharing and for dealing with writes, e.g. I wonder what dyn.com do?
> Anyone on the list know?
>
> Cheers,
> --/Saleem
>
>
>
> On 06 Feb 2018, at 15:57, AshwoodsmithPeter <[email-masked]>
> wrote:
>
> >Perhaps I have not understood your comment, but there is only one DNS
> record to update when a node moves, as long as that record is not cached
> (see my previous email about setting TTL low), so that is O(1) also.
>
> Hey Saleem,
>
> To scale a state distribution system you need N=1000’s of servers to
> spread the client’s read/write/query load. Any client can send a
> read/write/query to *any* server and ideally at huge scales the client
> load on servers should balance out.  I.e. each server handles
> #Users/#servers of the load. You can approach this several ways:
>
> 1-     A message to write arrives at an arbitrary server from a client,
> it then has to send a copy to all N other servers. That yields O(N) write
> messages and O(1) read messages. This is only good when there are vastly
> more read’s than writes.
> 2-     A message to write arrives at an arbitrary node, no copies are
> made, a read requires O(N) messages to find this on another server. This is
> only useful when there are vastly more writes than reads.
> 3-     A message to write arrives at an arbitrary server, log(N) messages
> are used to find the proper server for this key, a read can now arrive at
> any arbitrary server and again log(N) messages allow you to find the
> previous server with the key. This approach can also be balanced on the fly
> by moving the keys from server to adjacent server (in constant time
> remarkably), and likewise client balance can also be adjusted on the fly by
> simple redirection embedded in the client server protocol.
>
> My point is that 3 is about the best you can do for both read/write while
> also spreading the client load. If you don’t care about spreading the
> client load or have a massive imbalance between reads and writes then there
> are better options (DNS/trees etc.) but I believe load spread, and even
> read/write performance is a requirement for a scalable mapping system for
> IDLOC and I suspect order analysis would show there is no theoretically
> better approach in terms of total messaging (at the limit).
>
> Cheers,
>
> Peter
>
>
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 6 Feb 2018 13:32:47 -0800

On Tue, Feb 6, 2018 at 6:17 AM, Saleem Bhatti <[email-masked]> wrote:
>
>
> On 06 Feb 2018, at 13:10, Dino Farinacci <[email-masked]> wrote:
>
> And DNS doesn’t have pubsub. So that means caching DNS entries need to poll
> for changes. That will make handoffs as fast as the polling interval.
>
>

Saleem,

I think Dino's point is that this results in constant polling of DNS
at some frequency. In order to reduce latency across a mobile event a
higher polling frequency is needed, but then a higher frequency means
more packets, more congestion and load on the network and DNS. Also,
even a period as small as 1s or 0.5s would create a noticeable latency
blip for real time applications like video chat, AR, VR, etc.

Tom

> scaling problem is undeployable at scale and therefore not useful to discuss
> in the context of any real deployment.
>
>
> ILNP uses DNS lookups (as for IP today) so that DNS names map to an Id/Loc
> pair. Then, nodes use direct signalling with Locator Updates as they move,
> and update DNS with new Locator values.
>
> Updating DNS securely is possible today with, but deployed DNS engineering
> is not optimised for write operations. At the current time, at least, there
> is a significant performance hit with using DNS in this way.
>
> So, overall, for ILNP, the scaling issues with Locator updates are related
> to the performance of secure DNS write operations.
>
> Cheers,
> --/Saleem
>
>

---

From: Saleem Bhatti <[email-masked]>
Date: Wed, 7 Feb 2018 09:53:50 +0000

Tom;

> On 06 Feb 2018, at 21:32, Tom Herbert <[email-masked]> wrote:
> 

My apologies if I have missed something.

However, I see the interaction with DNS -- at least for ILNP -- as:

a) a query by an end-system when it needs to set-up a connection to a remote (mobile) host - it needs the remote host's current location; or
b) when the mobile host moves and has to update DNS with its new Locator so a) can work correctly (an update to DNS might not necessarily happen every time a host moves to a new radio cell, but that depends on the network configuration).

So neither of those should require polling.

For a), that is pretty much as it is today - when you want to connect to a remote host, you resolve a name to an address (but in the case of ILNP, it is an I-L pair) - no polling of DNS is required.

For b), that is specific to ILNP and is the main overhead for mobility in order to allow correct routing of incoming connections to the mobile host.

If by, "mobile event", in your text above you mean, "handover between communicating end-systems", then that is handled in ILNP by Locator Update (LU) messages directly between the hosts that have a communication session in progress - DNS is not involved. For ILNP, that can be done with latency that is 1 RTT, and with ~zero loss using soft-handover at the IP layer (at least in my testbed experiments, that is what I am seeing - please see https://goo.gl/9yMuHe for more details).

I have done experiments with DNS on a campus network, with zero TTL for DNS A RRs, and the additional load for using zero TTL is not significant (please see https://goo.gl/z31vAF for details).

That is the basic mode of operation for ILNP, and there may be engineering tweaks and optimisations that I have not yet considered (in fact, there are scenarios presented in RFC6748).

For example, Peter Ashwood made a fair point about additional load for updates -- item b) above -- for a DNS service deployment which uses replication of state for enabling load distribution. Then, performance would very much depend on the engineering of a particular solution, and is not a constraint of DNS itself.

So, no polling of DNS, and handover latency at 1 RTT with ~zero loss during handover.

Have I missed something?

(By the way, I am not averse to mechanisms other than DNS for "mapping" or name resolution, but I believe that DNS is an option.)

Cheers,
--/Saleem

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Feb 2018 16:03:53 +0100

Le 06/02/2018 à 14:10, Dino Farinacci a écrit :
> And DNS doesn’t have pubsub.

Not sure about 'sub' but there is 'pub' in that DHCP clients can update 
DNS resource records.

Alex

  So that means caching DNS entries need to
> poll for changes. That will make handoffs as fast as the polling interval.
> 
> Dino
> 
>>> On Fri, Feb 2, 2018 at 4:34 AM, Behcet Sarikaya 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     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.
>>
>> ILNP uses DNS lookups (as for IP today) so that DNS names map to an 
>> Id/Loc pair. Then, nodes use direct signalling with Locator Updates as 
>> they move, and update DNS with new Locator values.
>>
>> Updating DNS securely is possible today with, but deployed DNS 
>> engineering is not optimised for write operations. At the current 
>> time, at least, there is a significant performance hit with using DNS 
>> in this way.
>>
>> So, overall, for ILNP, the scaling issues with Locator updates are 
>> related to the performance of secure DNS write operations.
>>
>> Cheers,
>> --/Saleem
>>
>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 8 Feb 2018 09:12:38 +0900

> On Feb 8, 2018, at 12:03 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Not sure about 'sub' but there is 'pub' in that DHCP clients can update DNS resource records.

I meant notification support. So if Alex.com is what I look up and you change a AAAA record for Alex.com - I don’t get informed. 

Dino