
<!DOCTYPE html>

<html>

<head>

<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">

</head>

<body>

<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">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.</p>

<p dir="auto">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. </p>

<p dir="auto">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.</p>

<p dir="auto">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.</p>

<p dir="auto">Intuitively this should cut down the amount of multicast by a dramatic amount.</p>

<p dir="auto">DaveO.<br>

 </p>

<p dir="auto">On 29 Apr 2019, at 0:05, Ernest Andrew McCracken (emccrckn) wrote:</p>

</div>

<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="1B020C3C-CB13-4084-906E-B5B0CDD770A8">

<div dir="ltr">

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

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.</div>

</div></div></blockquote>

<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">

</blockquote><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">_______________________________________________<br>

Nfd-dev mailing list<br>

Nfd-dev@lists.cs.ucla.edu<br>

<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev" style="color:#777">http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev</a></p>

</blockquote><p dir="auto">DaveO</p>

</div>

</div>

</body>

</html>