[Nfd-dev] about the relation between FIB and feedback from (un)successful interests

[David R. Oran]

On 31 Oct 2019, at 15:30, Lixia Zhang wrote:

> I'm on the flight to Boston
If you’re around and want to chat, let me know. I’m here in 
Cambridge all this week and most of next.

> and catching up my notes from yesterday: we spent time on this issue 
> of how to handle the relation between FIB and feedback from 
> (un)successful Interests, and I just want put down my view (at this 
> time) in words, in case I did not express it clearly during the call
>


> 1/ we keep different things separately: FIB state is FIB state, 
> interest feedback is recorded somewhere else (I dont know exactly 
> where it is now)
>
Most any QoS sensitive routing or congestion scheme needs a way to 
accumulate state about what happened to related sets of packets. I think 
you’re right that the FIB is unlikely to be the right place to do this 
(due to state granularity being too coarse in most cases).

> 2/ strategy looks all the info available to it and makes forwarding 
> decisions for future interests
>
> 3/ So we just need a clear design of the following:
> a) the prefix granularity of the impact from (un)successful interest, 
> and
> b) the time scale of this impact (i.e. how long to remember this)
>
> 3.a: if we take a "slow-start" spirit, i.e. being conservative until 
> we learn better, a simple way to decide the prefix granularity is just 
> take the name of successful/unsuccessful interest minus last 
> components.

I’m not a fan of this, since it’s pretty arbitrary and tries to 
“psych out” what the equivalence classes of packets are for 
different applications. What about one of the two approaches in 
https://datatracker.ietf.org/doc/draft-moiseenko-icnrg-flowclass/ ?

> e.g. this makes sense in streaming data (supposedly the last component 
> is sequence number)
> for continued success, we dont change the prefix;
> for continued failure: we need to understand what are the shared 
> prefixes between those failed interests to decide whether we want to 
> extract out more components from the end of the prefix.
>
> 3.b: maybe we can just follow standard soft state design, i.e. 
> continued use of the information (which prefix succeeds/failed using 
> which face) will rest the timeout, otherwise the information times out 
> and get removed.
>
Timeouts are fine, but you may want some optimizations that discard 
information more aggressively after topology changes.

> Thoughts?
>
> Feel free to share with whoever interested, but I dont think this is 
> ready to go nfd-dev list at this time (Junxiao, I will archive this 
> msg)
>
> Lixia
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

DaveO