[Nfd-dev] NFD Call: Multicast Suppression Slide Deck

[David R. Oran]

I just had a chance to look at this. Jittering forwarding/replies does 
help, as numerous studies in the past for reliable multicast protocols 
have shown. So I think what you’ve got, modulo perhaps more clever 
adaptation to the timers based on load on the subnet is a good policy.

What seems entirely missing here is any way to adaptively switch between 
unicast and multicast. There’s no point in continuing to multicast 
once you have enough state to “lock onto” a next hop that satisfies 
your interests.

Any node/forwarder receiving a multicast Interest knows this by the 
destination L2 address being multicast rather than unicast. That means 
you should never multicast Data in reply if the Interest was sent 
unicast. Conversely, if you sent an Interest multicast and receive any 
reply (either multicast or unicast) you can remember the L2 address of 
the first response (after validation, of course) and subsequently 
unicast your interest there until either you get a NAK for no path or 
congestion (or timeout) or you start seeing RTTs increasing, when you 
can revert to multicast.

In order to reduce the probability that two consumers are 
de-synchronized by enough that they would lock onto different next hops 
for the same interests, if you receive a multicast interest and you 
still have PIT state (or keep some extra intro for short period after 
satisfying an interest) you should respond immediately with a unicast 
Data reply. If you don’t have such state, then invoke your multicast 
reply jitter timer. This ensures that for a given interest within a 
reasonable time window multiple consumers lock onto the same next hop.

Intuitively this should cut down the amount of multicast by a dramatic 
amount.

DaveO.


On 29 Apr 2019, at 0:05, Ernest Andrew McCracken (emccrckn) wrote:

> As per discussed on the last NFD call these are the slides for a 
> proposed suppression mechanism for multicast suppression for both 
> interest and data traffic on a wireless medium.  The assumption here 
> is the nodes participating are in infrastructure mode.  I will also 
> try to find the bluejeans archive call for this.


> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

DaveO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20190509/0fcb8b16/attachment.html>