[Nfd-dev] namespace-based strategy choice weakness

[Junxiao Shi]

Hi Klaus

The network administrator should ensure that there isn't a strategy
"clearly superior" than others available for selection by any applications.
Consider an ISP network, there could be superior strategies, but they
should always be configured under a certain namespace that corresponds to
the ISP's own services.
If a superior strategy is available for selection under other namespaces,
nothing stops every application to select it, because only allowing a
subset of application (other than ISP's own services) to select this
strategy would be a violation of network neutrality.

If application developers are allowed to supply the strategy (through an
Interest header field or routing announcements), restrictions could be
placed on the overhead caused by those strategy, such as:

   - in any 60sec period, the number of outgoing Interests transmitted by
   the strategy is no more than 110% of incoming Interests
   - on average, at most 64 octets of measurements information can be
   stored per PIT entry
   - on average, at most 1ms CPU core time is permitted per incoming
   Interest for strategy program execution

Such restriction can be uniformly placed onto every strategy (for
non-ISP-owned services) so it's fair to every application.

Yours, Junxiao

On Wed, Jul 6, 2016 at 5:36 PM, Klaus Schneider <klaus at email.arizona.edu>
wrote:

>
> Yes there is often a trade-off between things like throughput, delay and
> reliability. This will hopefully minimize the incentive to mislabel the
> preferred strategy.
>
> However, I'm not sure if that works in practice. It can become a problem
> when some strategies are clearly superior than others, like IP QoS classes
> ("best-effort", "expedited forwarding", "assured forwarding", etc.)
>
> Or if some strategies (like broadcast) create a much higher overhead than
> others.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160710/b2162ecf/attachment.html>