Project

General

Profile

Task #3513

[NdnCon] Change user prefix to be compatible with auto prefix propagation

Added by Junxiao Shi about 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
Due date:
03/16/2016
% Done:

100%

Estimated time:

Description

Currently, NdnCon creates the user prefix like ndn:/ndn/guest/ndnrtc/someone%40example.com, and publishes streams under this prefix.
Reachability of this user prefix depends on nfd-autoreg which adds a back-route like ndn:/ndn/guest that is same for every user, and forwarding relies on flooding by AccessStrategy which is inefficient (#3219).

This causes increased Interest traffic toward all hosts connected to a gateway router, if any host is publishing a stream.

To solve this problem, NdnCon should change the user prefix to like ndn:/ndn/guest/someone%40example.com/ndnrtc.
When the end host is configured with a testbed certificate ndn:/ndn/guest/someone%40example.com, automatic prefix propagation will create a back-route for ndn:/ndn/guest/someone%40example.com that is unique for each participant.

A more specific prefix of each participant allows AccessStrategy to forward Interests toward the correct host, and flood only if the same participant has multiple hosts connected which is unlikely.
This shall decrease Interest traffic on other hosts, and thus decrease CPU usage and network congestion.

auto-prefix-propagation-tr.pdf (586 KB) auto-prefix-propagation-tr.pdf Jeff Burke, 03/06/2016 08:11 AM

Related issues

Related to NFD - Bug #3219: AccessStrategy measurements ineffective for NDN-RTC trafficNew2015-09-21

Related to ndnrtc - Task #3512: Prep for March 9 seminar with NDN-RTCClosed2016-03-04

Blocked by NFD - Task #3515: Request all expired node and user certificates be manually updatedClosed2016-03-05

History

#1 Updated by Junxiao Shi about 3 years ago

Changing the user prefix does not eliminate NdnCon's dependency on nfd-autoreg.
nfd-autoreg is still used to create back-route for ndn:/ndn/broadcast which is used for conference discovery and chatroom services.
However, the bulk of Interests are no longer flooded, so it's still beneficial.

Also, automatic prefix propagation itself depends on nfd-autoreg to fetch certificates, but the traffic volume is much smaller.

More information about automatic prefix propagation can be found in NDN Memo: Automatic Prefix Propagation, to be published as a technical report.
Contact @Yanbiao for a draft.

A dependency of using automatic prefix propagation is for every participant to have an NDN testbed certificate.
Currently, ndncert is broken that operators cannot issue certificates and site certificates are expiring.
These must be fixed before users can request certificates.

#2 Updated by Junxiao Shi about 3 years ago

  • Related to Bug #3219: AccessStrategy measurements ineffective for NDN-RTC traffic added

#3 Updated by Alex Afanasyev about 3 years ago

The issue description is not correct. The change must not be done blindly to ndn:/ndn/guest/someone%40example.com/ndnrtc form. The prefix name should be inferred from the NDN certificate that is currently installed on the system, which can correspond to guest or testbed-site specific prefix. This namespace is equivalent to "identity" of the certificate.

For example, my cert is

  • /ndn/edu/ucla/KEY/cs/aa/ksk-1456347954445/ID-CERT/%FD%00%00%01S%15%1A%BE%08

The corresponding identity and namespace under which I can publish (and automatically propagate)

  • /ndn/edu/ucla/cs/aa

#4 Updated by Jeff Burke about 3 years ago

  • Assignee changed from Jeff Burke to Peter Gusev

I don't have a current email for Yanbiao (just tried it) - can someone else please post the draft here, or give me his email?

Also, is automatic prefix propagation deployed?

#5 Updated by Jeff Burke about 3 years ago

  • Blocked by Task #3515: Request all expired node and user certificates be manually updated added

#6 Updated by Jeff Burke about 3 years ago

Draft TR on automatic prefix propagation uploaded.

#7 Updated by Jeff Burke about 3 years ago

Peter, can you comment on the impact on the application, and whether we can roll this into the next release and text on Wednesday?

#8 Updated by Junxiao Shi about 3 years ago

is automatic prefix propagation deployed?

Yes.

Automatic prefix propagation is a feature in end hosts. It's implemented since NFD 0.4.0.

It relies on prefix registration commands under /localhop/nfd prefix, which is enabled on NDN testbed since 2015.

#9 Updated by Peter Gusev about 3 years ago

Need to clarify implementation details for myself first.

Alex Afanasyev wrote:

The issue description is not correct. The change must not be done blindly to ndn:/ndn/guest/someone%40example.com/ndnrtc form. The prefix name should be inferred from the NDN certificate that is currently installed on the system, which can correspond to guest or testbed-site specific prefix. This namespace is equivalent to "identity" of the certificate.

For example, my cert is

  • /ndn/edu/ucla/KEY/cs/aa/ksk-1456347954445/ID-CERT/%FD%00%00%01S%15%1A%BE%08

The corresponding identity and namespace under which I can publish (and automatically propagate)

  • /ndn/edu/ucla/cs/aa

User can have multiple NDN certificates installed, can't she? Thus she must explicitly select which certificate to use, right?
Right now, registering routes is simply: $ nfdc regsiter / udp://<hub>. How different it will become with this approach?

#10 Updated by Peter Gusev about 3 years ago

  • Related to Task #3512: Prep for March 9 seminar with NDN-RTC added

#11 Updated by Junxiao Shi about 3 years ago

User can have multiple NDN certificates installed, can't she? Thus she must explicitly select which certificate to use, right?

I suggest providing a dropdown menu for the user to select an identity; a user cannot publish any stream before a valid identity is selected.

An identity (and thus the user prefix) is globally reachable only if the connected gateway router announces a prefix of it, thus the end host must connect to the correct gateway router.
Application may verify the prefix is announced by the connected gateway router by local prefix discovery procedure.

Right now, registering routes is simply: $ nfdc register / udp://<hub>. How different it will become with this approach?

It's best to connect with ndn-autoconfig tool.

Otherwise, the end host must also manually register ndn:/localhop/nfd toward the gateway router to trigger automatic prefix propagation.

#12 Updated by Anonymous about 3 years ago

  • Subject changed from [NdnCon] Change user prefix to be compatible with auto prefix propagation to [[NdnCon]] Change user prefix to be compatible with auto prefix propagation

#13 Updated by Anonymous about 3 years ago

  • Subject changed from [[NdnCon]] Change user prefix to be compatible with auto prefix propagation to [NdnCon] Change user prefix to be compatible with auto prefix propagation

#14 Updated by Anonymous about 3 years ago

  • Description updated (diff)

#15 Updated by Jeff Burke about 3 years ago

  • Due date set to 03/16/2016

Targeting completion for this week's demo, if possible. (I realize headless consumer/producer is priority, but perhaps that's not needed until the retreat? Seeing the impact of working around the access strategy problem during the 3/16 test would be beneficial.)

#16 Updated by Peter Gusev about 3 years ago

@Junxiao is there a defined structure for certificate name which I can use to infer a prefix? I.e. in this example:

/ndn/edu/ucla/KEY/cs/aa/ksk-1456347954445/ID-CERT/%FD%00%00%01S%15%1A%BE%08

Should prefix be composed of anything before KEY and between KEY and ksk-.*?

#17 Updated by Alex Afanasyev about 3 years ago

The libraries organize certificates under concept of identity. You just need to take the identity (enumerate available identities).

#18 Updated by Peter Gusev about 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 70

Added basic functionality to ndncon for choosing signing identity among available. Requires to be finished up and tested.

#19 Updated by Junxiao Shi almost 3 years ago

At 20160324 NFD call, Alex points out that changing the user prefix is not a prerequisite of using automatic prefix propagation.
One can enter /ndn/edu/ucla/aa to NDN publishing prefix box, which would generate a user prefix that falls under this identity name which is compatible with automatic prefix propagation.
Therefore, this issue does not block #3568.

However, Alex still suggests proceeding with this issue as a UI improvement.

#20 Updated by Peter Gusev almost 3 years ago

@Junxiao, ndncon has test producers (and there will be arbitrary number of producers for large scale tests in the nearest future). I assume all of these need to have a testbed certificate to be discoverable, right? How should we generate these certs?

#21 Updated by Junxiao Shi almost 3 years ago

Answer to note-20:

Suppose /ndn/edu/ucla/remap/mrfoo wants to run two test producers demo1 and demo2, he can creates two keys and sign them with his main testbed certificate.
The two keys would have identities /ndn/edu/ucla/remap/mrfoo/demo1 and /ndn/edu/ucla/remap/mrfoo/demo2.

These two keys should be published by mrfoo in his own repository.
This repository listens on prefix /ndn/edu/ucla/remap/mrfoo/KEY, and can run on either or both hosts, or on another machine.
Consumers who want to verify the packets from test producers will be retrieving certificates from this repository.
mrfoo's main testbed certificate is already available on the repository on REMAP gateway router, and is not served from this repository.

As an implication of #3568 before #2766, only certificates directly requested from ndncert can be used with automatic prefix propagation.
Thus, mrfoo must install his main testbed certificate into the NFD KeyChain on both test producers, and the machine with his key repository if it's separate.
Since automatic prefix propagation prefers the shortest identity, the main testbed certificate will be used to register the back routes.

An unfortunate consequence is that both test producer will have the same back route prefix /ndn/edu/ucla/remap/mrfoo instead of the more accurate /ndn/edu/ucla/remap/mrfoo/demo1 and /ndn/edu/ucla/remap/mrfoo/demo2.
This can lead to inefficiency in #3219, but it would only affect mrfoo's test producers and does not impact other users.
This limitation can be lifted only after #2766 and related changes, after which mrfoo can delete his main testbed certificate from the test producers so that a more accurate prefix will be registered by automatic prefix propagation.


Large scale tests are more complicated.
In those tests, an experimenter may need to connect a producer to a gateway router other than his own institution.
To have automatic prefix propagation register a prefix under another institution's routable prefix, a certificate under that institution is needed.

I've proposed ndncert Issue 4 that would allow an experimenter to request a certificate at another institution, and ndncert Issue 5 that automates the certificate issuance procedure so the experimenter can write a script to request certificates from all institutions (the script can also access the email inbox and click the link automatically).

#22 Updated by Peter Gusev over 2 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 70 to 100

Also available in: Atom PDF