[Nfd-dev] namespace-based strategy choice weakness

[Klaus Schneider]

Hi Susmit and Junxiao,

>> b)
>> Each strategy optimizes for a different goal, such as lower delay,
>> higher throughput. It does not prioritize traffic of one application
>> over another.
>> If you mislabel web traffic as download traffic, you get higher
>> throughput but possibly more delay so navigation actions are less
>> responsive.

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.


I like the idea of using a header field for the strategy choice:

>
> To support this use case, an Interest can carry a strategy choice field. NFD can choose a strategy according to this field.
> We could either put a strategy name into this field and let NFD retrieve the strategy program, or put some generic preferences in this field and let NFD pick a strategy that best matches those preferences.
> The bandwidth overhead of this field is less of a concern, because it would be much smaller than a Link object.
> A major challenge in this second idea is that it's unclear which strategy would be used if Interests sharing the same PIT entry from different consumers are asking for different strategies. It's certainly undesirable to split into multiple PIT entries based of different strategy choice and send packets multiple times.
>

Maybe use "first come, first serve" (i.e., the first Interest determines 
the strategy of the PIT entry).

Or use some sort of cumulative logic: Let's say the first Interest wants 
"shortest path", so it is forwarded on the shortest path. A later 
Interest wants "broadcast", so then it is sent out on the remaining 
faces. (Just throwing out ideas. I can see a number of problems here, 
like messing up RTT measurements and overhead).

Also, does the strategy choice in the header field determine the 
strategy of all routers? What if you want "shortest path" on all the 
routers inside the network, but "access strategy" on the last hop?

Best regards,
Klaus




On 05.07.2016 13:56, Junxiao Shi wrote:
> Hi Susmit
>
> a)
> This question is orthogonal to my post. I'm talking about /what/ goes
> into the strategy choice table and how are the entries interpreted, not
> /where/ those entries come from.
> Today it's a local configuration by admin of each router / end host.
> "expressing strategy choice through routing protocols" is a different
> idea under discussion.
>
> b)
> Each strategy optimizes for a different goal, such as lower delay,
> higher throughput. It does not prioritize traffic of one application
> over another.
> If you mislabel web traffic as download traffic, you get higher
> throughput but possibly more delay so navigation actions are less
> responsive.
>
> Yours, Junxiao
>
> On Mon, Jul 4, 2016 at 6:15 PM, Susmit <susmit at cs.colostate.edu
> <mailto:susmit at cs.colostate.edu>> wrote:
>
>     >
>     > NFD can choose effective strategy from a marked component.
>     > Instead of doing longest prefix match in the strategy choice table, a
>     > strategy choice entry can indicate:
>     >
>     > contains "app=ndncon" => realtimeI'
>     > contains "app=ndnfs" => high-throughput
>
>     Two questions,
>
>     a) Who is responsible for configuring strategies? Operators or users?
>     Should users be responsible for finding optimal stategies in the
>     network?
>
>     b) How are we going to stop people from mislabeling Interests?
>     Hypothetically speaking, If web search strategy is
>     "normal-throughput", pages will load faster if they are labeled
>     "high-throughput".
>
>     Thanks.
>
>     --
>
>     Regards,
>     Susmit
>
>     ====================================
>     http://www.cs.colostate.edu/~susmit
>     <http://www.cs.colostate.edu/%7Esusmit>
>     ====================================
>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>