Subject: quick question on draft-vyncke-6man-mcast-not-efficient

From: 神明達哉 <[email-masked]>
Date: Wed, 26 Feb 2014 10:47:34 -0800

I have one quick question on the draft.

In Section 3.5, it states:

   NDP cache needs to be maintained by refreshing the neighbor cache for
   entries which are in the STALE state.  This requires yet another
   Neighbor Solicitation / Neighbor Advertisement round.

What specifically does this mean?  Simply because a node has a
STALE neighbor cache entry doesn't immediately mean an additional
NS/NA exchange.  In fact, RFC 4861 even prohibits it:

      STALE       The neighbor is no longer known to be reachable but
                  until traffic is sent to the neighbor, no attempt
                  should be made to verify its reachability.

If there's actual traffic to/via that neighbor, it *may* involve NS/NA
('may' because it could even be optimized out if the node implements
the optimization for the DELAY state and applies it), but in that case
the main traffic itself would "wake up mobile devices" anyway, so I
don't understand the point of this discussion.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 27 Feb 2014 11:05:33 +0900

> don't understand the point of this discussion.

What he said.

I don't understand what the problem is either.

   1. 1. If it's multicast traffic we're worried about, then this traffic
   is unicast and we shouldn't be worried about it. If the IP to MAC mapping
   has expired from the ND cache, then why did it expire?
      1. If it expired because the router overflowed the ND table (i.e., it
      thought it was keeping too much state and had to throw it away), then
      there's no way to fix that - even address registration won't
help, because
      the amount of state is the same.
      2. If it didn't expire due to state exhaustion, well, implementations
      can fix this problem it by simply *not expiring ND cache entries
when they
      don't need to*.
   2. If it's raw packets and battery impact we're talking about, then...
   you're sending that neighbour unicast packets already, so it's awake and
   using power. The additional traffic caused by one 72-byte unicast packet
   every 30 seconds seems like something that's not worth worrying about
   except in the most remote of corner cases.

If it ain't broke, don't fix it.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 27 Feb 2014 16:11:09 +0000

Jin and Lorenzo,

Thanks for reading the draft. And, indeed the only issue is some more unicast traffic (at IP and MAC layer) as indicated in the draft. But, you are right, it is nearly nothing more on the bandwidth and it has nearly zero impact on battery life => this section will be removed

Thanks again

-éric

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: mercredi 26 février 2014 18:05
To: 神明達哉 <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: quick question on draft-vyncke-6man-mcast-not-efficient
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Andrew Yourtchenko <[email-masked]<mailto:[email-masked]>>, Eric Abegnoli <[email-masked]<mailto:[email-masked]>>, Eric Vyncke <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: mercredi 26 février 2014 18:06

On Thu, Feb 27, 2014 at 3:47 AM, 神明達哉 <[email-masked]<mailto:[email-masked]>> wrote:

What he said.

  1.  1. If it's multicast traffic we're worried about, then this traffic is unicast and we shouldn't be worried about it. If the IP to MAC mapping has expired from the ND cache, then why did it expire?
     *   If it expired because the router overflowed the ND table (i.e., it thought it was keeping too much state and had to throw it away), then there's no way to fix that - even address registration won't help, because the amount of state is the same.
     *   If it didn't expire due to state exhaustion, well, implementations can fix this problem it by simply *not expiring ND cache entries when they don't need to*.
  2.  If it's raw packets and battery impact we're talking about, then... you're sending that neighbour unicast packets already, so it's awake and using power. The additional traffic caused by one 72-byte unicast packet every 30 seconds seems like something that's not worth worrying about except in the most remote of corner cases.