Subject: [homenet] Despair

From: Sander Steffann <[email-masked]>
Date: Wed, 5 Aug 2015 11:22:51 +0200

Hi,

All these discussions about the routing protocol are making me despair... What the *** is wrong here in the IETF? What happened to producing working solutions and specs? All this discussion about which routing protocol is capable of doing what, "my protocol is as good as yours", bashing each other's ideas, twisting each others words. People, this is just pathetic. There are dozens of routing protocols that could be made to work in homenet. But we already have one that is working today. With time there will always be new ideas and improvements. And if we keep waiting for that we never get anything done. Do we want a 'perfect' protocol in years or do we want a good solution today? We have what we need: let's move on...

Cheers,
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 11:48:05 +0200 (CEST)

On Wed, 5 Aug 2015, Sander Steffann wrote:

> All these discussions about the routing protocol are making me 
> despair... What the *** is wrong here in the IETF? What happened to 
> producing working solutions and specs? All this discussion about which

Yes, in the IETF this is typically done in working groups. Last I checked, 
there wasn't a working group for Babel.

> routing protocol is capable of doing what, "my protocol is as good as 
> yours", bashing each other's ideas, twisting each others words. People, 
> this is just pathetic. There are dozens of routing protocols that could 
> be made to work in homenet. But we already have one that is working 
> today.

As far as I can tell, we have two, of which one is well known in the IETF, 
has a working group that is well attended with people from different 
organisations, has 20+ implementations total and has 20+ years of 
experience and shown extendability, and has multiple extensive commercial 
testing suites against which implementations can be validated.

The other one is experimental, doesn't have a working group, and seems to 
have more of a FOSS/Linux style development model with a single "real" 
implementation. Some might say this is better than what the IETF does, but 
others do not.

> we keep waiting for that we never get anything done. Do we want a 
> 'perfect' protocol in years or do we want a good solution today? We have 
> what we need: let's move on...

That's your opinion.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Sander Steffann <[email-masked]>
Date: Wed, 5 Aug 2015 12:00:36 +0200

Hi Mikael,

> As far as I can tell, we have two, of which one is well known in the IETF, has a working group that is well attended with people from different organisations, has 20+ implementations total and has 20+ years of experience and shown extendability, and has multiple extensive commercial testing suites against which implementations can be validated.
> 
> The other one is experimental, doesn't have a working group, and seems to have more of a FOSS/Linux style development model with a single "real" implementation. Some might say this is better than what the IETF does, but others do not.

Ok, so this discussion is more about following established procedure and about age of the protocol then. Glad to finally see the real arguments on the table :)

Cheers,
Sander

PS: yes, I know I am exaggerating, but we need to break out of this deadlock

---

From: Ray Bellis <[email-masked]>
Date: Wed, 05 Aug 2015 11:07:23 +0100

Please, let's draw a line under this whole argument for now.

The Design Team has been tasked with drawing up a brief requirements
document as soon as possible and we will then try to get WG consensus on
that.

We need *constructive contributions* that will aid the Design Team.
Anything else routing-related is off-topic.

thanks,

Ray

---

From: Dave Taht <[email-masked]>
Date: Wed, 5 Aug 2015 13:44:49 +0200

> Anything else routing-related is off-topic.

I would like to require the design team

*to actually install the software*.

>
> thanks,
>
> Ray
>
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

---

From: Ray Bellis <[email-masked]>
Date: Wed, 05 Aug 2015 13:34:36 +0100

> *to actually install the software*.

Dave,

We've heard you before, but with the best will in the world we cannot
*require* IETF volunteers to put their own time and money into this.

Heck, I can't even run the Homenet stack myself as my ISP doesn't yet
have native IPv6 and also wants extra money to get their edge router
running in bridge mode.

[and no, before you suggest it, changing ISPs is *not* an option].

Ray

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Aug 2015 13:43:26 +0100

> On 5 Aug 2015, at 13:34, Ray Bellis <[email-masked]> wrote:
> 

I see the homenet wiki content is 4 years old - http://tools.ietf.org/wg/homenet/trac/wiki 

Perhaps Dave/Juliusz/Markus could be allowed to add info there about their
implementations for Babel+HNCP? That might help people find and use the
info… even if not as yet formally an adopted WG solution.

If there’s an open source IS-IS based solution, then that could also be posted there,
so those interested in exploring both approaches could get hands-on experience?

Tim

---

From: Dave Taht <[email-masked]>
Date: Wed, 5 Aug 2015 14:48:09 +0200

> *require* IETF volunteers to put their own time and money into this.

Stay home and save the plane fare and hotel and food expenses.
Attending a meeting costs 3k or so, plus the lost business from trying
to stay awake in futile meetings.

That's what I've been doing. Pays for a lot of routers, that does.
Gives me time to work on the remaining real problems, also, which
include naming the ipv6 hex vomit more sanely and a multitude of other
issues this wg has dropped the ball on.

If whoever is funding your travel is unwilling to let you expense a
couple 100 dollar (tops) routers, in addition to allowing you to waste
time attending meetings, I think they are investing in the wrong
place.

Nobody funds my travel, and I guess, in part, that is why I am aware
of the overwhelming difference in cost between actually developing and
testing the software, vs attending meetings or putting up with the
endless bikeshed emails.

> have native IPv6 and also wants extra money to get their edge router

Nearly every form of ipv6 tunneling is supported by the openwrt
software for your edge gateway.

dslite, 6in4, aiccu, 6to4, 6rd, and gre

are supported and have been supported *for years*. Numerous other
methods of applying a ipv6 vpn over ipv4 also exist.

If you provider will not allow any of those through their crappy cpe,
then perhaps this wg needs to consider that as a problem for this wg?

Sure, that first router requires some hand configuration for the
needed tunnels. Additional ones do not, and can thus be tested with
hnetd and your routing protocol of choice.

http://wiki.openwrt.org/doc/uci/network for more details as to setup.

> [and no, before you suggest it, changing ISPs is *not* an option].

Not being able to get native ipv6 to your location is no excuse.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 5 Aug 2015 10:45:16 -0400

Dave - I'm responding to your e-mail but my post is aimed at the homenet WG as a whole, because your e-mail gives me an opportunity to pull on a couple of threads from my perspective as a DT member.

You suggested installing the software.  OK, I could install it on my home network, but I would gain exactly zero insight into the problem from that installation.  My home network has one router, and everything inside my home is bridged.

I do have native IPv6 (thanks, JohnB and Comcast) in my home, through a Linksys router with an old, internal software build from Cisco.  That router waited patiently until it got a DHCPv6-PD delegation from Comcast and then silently started advertising the prefix.  I didn't notice that the Comcast IPv6 service had been added to the tunnel service I was using until I happened to notice a new prefix on one of the devices on the home network.  I shut down the tunnel and everything just worked...a demonstration of graceful renumbering (admittedly not a very complicated demo, but one in a real, operational network) on running code.

So, as you suggest, I could go buy a couple of routers and run the software on a more complex topology.  How do I decide where to put those routers so I can learn anything about the protocols?  I don't ever intend to use any of my wireless as a transit link.  I have a wired link up to the second floor with a switch and an AP to improve coverage on the second floor, but no redundancy so there's no advantage to adding a router in front of the switch.  Where's the advantage in running a collection of self-configuring routers in my current network?

OK, I could invent a new topology that might take some advantage of the routers.  How do I choose that topology?  What are the requirements I'm trying to test?  Where do I find a couple of weeks to perform experiments?

Therefore, in my estimation, I *might* learn something more than I know now by spending a significant amount of my time or my employer's time in a series of experiments using deployments of the alternative routing protocols on hypothetical network topologies and use cases.  I don't see how that knowledge is going to help me solidify the requirements or answer the questions Russ talked about in his report from the DT in Prague.

- Ralph

> On Aug 5, 2015, at 8:48 AM 8/5/15, Dave Taht <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Aug 2015 10:01:29 -0700

There are a lot of things wrong in the IETF. And there are some good things about the IETF. 

Let’s just keep the discussions technical. We may have to be subjective, but that is the right of openness. But folks shouldn’t take it personally.

I want to make one comment about Babel, or more to the point the DUAL algorithm. I, with one other engineer were the original designers of EIGRP in the early 90s. We worked with Jose Garcia-Luna from SRI/UCSC on implementing the DUAL algorithm in EIGRP.

Just be careful about the claim that DUAL is loop-free. It is loop-free because the toplogy stays in DUAL acitve-state until it is safe to change, but during that time, packets are black-holed.

This is not a strike against Babel or me being opposed to it.

Also, IS-IS can be made to run in unicast-mode and not link-layer multicast if the urge is too great to avoid multicast transmission. We did this with an adjacecny-server model when designing OTV. That is, IIHs are unicasted to a preconfigured DR (ie adjacency-server), which replicates IIHs to all other routers that are discovered. All routers believe they are adjacent to each other just all physical transmission unicast hair-pins to the adjacency-server. There can be more than one adjacency-server and they test liveness to each other so one can be the forwarder.

Dino

> On Aug 5, 2015, at 2:22 AM, Sander Steffann <[email-masked]> wrote:
> 
> Hi,
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2015 12:58:55 -0400

Dave Taht <[email-masked]> wrote:
    >> document as soon as possible and we will then try to get WG consensus
    >> on that.

    > *to actually install the software*.

I agree, but Dave, in the absense of this, and as someone that I know has run
at least one of the protocols in production (BABEL), can *you* see a reason
why BABEL won't work?

Can you see a reason why ISIS won't work?

Because this is what rough consensus is.  Not that X is better than Y,
but whether X or Y is unable to fullfil some requirement.

My conclusion is that both can be configured(in source code)/provisioned to
things correctly, and we should simply flip a coin.

(And I still don't know why we abandonned OSPFv3)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 13:26:52 -0400

On Aug 5, 2015, at 1:01 PM, Dino Farinacci <[email-masked]> wrote:
> Let’s just keep the discussions technical.

This is a great sentiment, but in fact on a technical level there is no reason to prefer Babel(now) over IS-IS(later).   Nobody is making the claim that IS-IS can’t be tweaked until it performs as well as Babel on a homenet.   The claim is that it doesn’t work well now, and it would be a new research project to fix it so that it does work.

Of course, your entirely just rejoinder to this will likely be “can you prove that Babel(now) works better in the homenet context than IS-IS(now).”   And for that the only response that I think is particularly convincing is that Babel is in active use in this context now and is working, and in addition that it has been extensively tested in battle-mesh meetings, and does well in that context (there are some open source competitors that also do well, but none are candidates for homenet because they don’t have RFCs that document them).   Battle meshes are not exactly like homenets, but they test the hell out of the case where Babel and IS-IS differ in their ability to support routing on the homenet.

If we had a smoking gun that showed that one protocol was decisively better than another, we already would have come to consensus.   I agree with Michael’s subsequent comment on this thread, though, and would add an additional point.   It is not the case that when half the working group wants one thing, and the other half wants a different thing, that we do not have consensus, because consensus is not voting.

Working group chairs often refuse to _call_ consensus when that situation prevails, or else don’t realize that they can, but they are not forbidden to do so.  Indeed it would save a lot of time if they did so now, and I think they reasonably could.   Dave Thaler did this last year in the PCP working group, and it was a very successful move that put an end to a really time-wasting dispute over trivia.   A dispute, I might add, that was very similar to this one.   It is not a simple process, and definitely isn’t a matter of a chair picking their favorite.  Dave did a lot of homework to describe the process he went through to make the decision.   The losing team was pretty pissed off, but they couldn’t really argue with the process, and as a result did not appeal.

IMHO this is actually better than tossing a coin, and I wish more working group chairs would do it.   Putting the responsibility for breaking the tie on a design team or on some magical future instance of the working group that has changed its mind (which is really what a requirements doc is going to do) is just kicking the ball further down the road.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 5 Aug 2015 17:33:15 +0000

Hey Dino, 

On 8/5/15, 1:01 PM, "homenet on behalf of Dino Farinacci"
<[email-masked] on behalf of [email-masked]> wrote:

>Let’s just keep the discussions technical. We may have to be subjective,
>but that is the right of openness. But folks shouldn’t take it personally.
>
>I want to make one comment about Babel, or more to the point the DUAL
>algorithm. I, with one other engineer were the original designers of
>EIGRP in the early 90s. We worked with Jose Garcia-Luna from SRI/UCSC on
>implementing the DUAL algorithm in EIGRP.
>
>Just be careful about the claim that DUAL is loop-free. It is loop-free
>because the toplogy stays in DUAL acitve-state until it is safe to
>change, but during that time, packets are black-holed.
>
>Also, IS-IS can be made to run in unicast-mode and not link-layer
>multicast if the urge is too great to avoid multicast transmission. We
>did this with an adjacecny-server model when designing OTV. That is, IIHs
>are unicasted to a preconfigured DR (ie adjacency-server), which
>replicates IIHs to all other routers that are discovered. All routers
>believe they are adjacent to each other just all physical transmission
>unicast hair-pins to the adjacency-server. There can be more than one
>adjacency-server and they test liveness to each other so one can be the
>forwarder.

The proposed IS-IS solution for link-layer multicast deficiencies is P2MP
operation - https://www.ietf.org/id/draft-lamparter-isis-p2mp-00.txt. We’d
be interested in your thoughts on this. Note that auto-config is a
mandatory requirement.

Thanks,
Acee 

>>today. With time there will always be new ideas and improvements. And if

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 5 Aug 2015 17:39:15 +0000

Just stick to multicast delivery but use long timeouts, and use (something like) bfd (with unicast) for actual neighbor aliveness.

Still sucks to tweak a routing protocol design for a broken l2 design (only unicast reliability provided for).

Sent from my Samsung Captivate Glide on AT&T

Dino Farinacci <[email-masked]> wrote:
There are a lot of things wrong in the IETF. And there are some good things about the IETF.

Dino

---

From: [email-masked]
Date: Wed, 5 Aug 2015 10:44:03 -0700

Agree Toerless. Resist the urge. :-)

Dino

> On Aug 5, 2015, at 10:39 AM, Toerless Eckert (eckert) <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Aug 2015 19:54:50 +0200 (CEST)

> (only unicast reliability provided for).

In November 2014 when I asked the IETF upper "brass" and the IEEE liasion 
to tell IEEE that they need to make multicast and broadcast work on wifi 
because most L3 protocols rely on it, including IPv4 and IPv6.

I don't know what happened after that, I didn't hear anything back. I 
asked multiple times.

I pinged them again just now, replying to the previous "ping" email on 
this issue from March 2015.

---

From: Dave Taht <[email-masked]>
Date: Wed, 5 Aug 2015 19:58:50 +0200

I regret that I am too busy this week to respond further on this thread.

For the record, I am helping implement the following test scenario at
battlemesh:

http://battlemesh-test-docs.readthedocs.org/v8/3-the-mesh-of-death-adversity.html

For those that would like a glimpse into some of the real problems
wifi has, and some of the solutions emerging for it,
I suggest some bedtime reading of the minstrel-blues stuff:

https://opus4.kobv.de/opus4-tuberlin/frontdoor/index/index/docId/3939

Which has been improving spacial reuse in this dense wifi environment
by a bit, there have also been other improvements in rate control, and
of course, the next big improvement in wifi I plan to work on is a
fq_codel-like implementation of per-station queueing, which should
improve the utilization of the 802.11n(and ac) mac by a lot, and
reduce induced latency, by lot.

But before then, we test, and gather data.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 5 Aug 2015 14:26:24 -0400

Hi Mikael,

> I don't know what happened after that, I didn't hear anything back. I

This is the first I've heard of your personal concern.  However, the need
to have multicast protocols work
better did come up when we recently rechartered PIM.  That turned into
"4) Optimization approaches for IGMP and MLD to adapt to link conditions in
wireless and mobile networks and be more robust to packet loss."

There is a draft that I noticed was recently
published
https://datatracker.ietf.org/doc/draft-mcbride-mboned-wifi-mcast-problem-statement/

I think that the issues need to be clearly articulated to hand work over to
IEEE.

Regards,

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Aug 2015 20:37:49 +0200

Hi,

> *to actually install the software*.

But that would not be properly following procedures.  This is the IETF,
and we (they, I have totally lost interest, tbh) have working groups, 
design teams, requirement documents, comparison documents, *more* 
requirement documents, ad-hoc committees, and I think someone mentioned 
a flash task force.

Pathetic indeed.

But as long as IS-IS gets another number of RFCs out of this, no harm done,
right?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 5 Aug 2015 18:46:18 +0000

Hi Alia,

On Aug 5, 2015, at 2:26 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mikael,

On Wed, Aug 5, 2015 at 1:54 PM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, 5 Aug 2015, Toerless Eckert (eckert) wrote:

In November 2014 when I asked the IETF upper "brass" and the IEEE liasion to tell IEEE that they need to make multicast and broadcast work on wifi because most L3 protocols rely on it, including IPv4 and IPv6.

I don't know what happened after that, I didn't hear anything back. I asked multiple times.

This is the first I've heard of your personal concern.

I had sent E-mails to Eric Gray and Glenn Parsons at least twice on this topic but didn’t receive a response. Eric seems to be the correct contact: http://www.ietf.org/liaison/managers.html

I guess we will need a formal liaison.

Thanks,
Acee

However, the need to have multicast protocols work
better did come up when we recently rechartered PIM.  That turned into
"4) Optimization approaches for IGMP and MLD to adapt to link conditions in wireless and mobile networks and be more robust to packet loss."

There is a draft that I noticed was recently
published https://datatracker.ietf.org/doc/draft-mcbride-mboned-wifi-mcast-problem-statement/

I think that the issues need to be clearly articulated to hand work over to IEEE.

Regards,

I pinged them again just now, replying to the previous "ping" email on this issue from March 2015.

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet

---

From: Alia Atlas <[email-masked]>
Date: Wed, 5 Aug 2015 14:50:03 -0400

Hi Acee,
Thanks for the extra context. Mikael forwarded me the email thread and I've
started one off-list including Dan Romascanu, who is very responsive and
helps coordinate and liaise with the IEEE.

I think we probably need a draft that describes the problems with
reasonable detail first - and articulates the assumptions that are made on
the link layer. That
will help make sure that we and the IEEE understand the issues involved.

Maybe that work can get coordinated with Mike McBride who's looking at this
area for multicast protocols also.

Thanks,
Alia

On Wed, Aug 5, 2015 at 2:46 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Alia,
>
> On Aug 5, 2015, at 2:26 PM, Alia Atlas <[email-masked]> wrote:
>
> Hi Mikael,
>
> I had sent E-mails to Eric Gray and Glenn Parsons at least twice on this
> topic but didn’t receive a response. Eric seems to be the correct contact:
> http://www.ietf.org/liaison/managers.html
>
> "4) Optimization approaches for IGMP and MLD to adapt to link conditions
> in wireless and mobile networks and be more robust to packet loss."
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2015 15:21:02 -0400

Ted Lemon <[email-masked]> wrote:
    > Working group chairs often refuse to _call_ consensus when that
    > situation prevails, or else don't realize that they can, but they are
    > not forbidden to do so. Indeed it would save a lot of time if they did

+1.

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Aug 2015 13:42:41 -0700

Chopps gave me the abridge version. I think its a good idea. But I don’t think its applicable in this use-case.

Dino

> On Aug 5, 2015, at 10:33 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> Hey Dino, 
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 5 Aug 2015 13:49:52 -0700

This is very simple to resolve. This is not a technical response.

(1) Have homenet adopt both protocols. Let the market decide. That means there may be routing protocol redistribution in the home. This would be a mistake.

(2) Pick one and move on. This has a chance of working if open source is available because vendors will take the quick-approach into delivering a solution. We saw this work with SNMP in the 90s (but this wasn’t an open-source case but a single reference implementation case).

(3) Pick one and hope it catches on. Vendors, if they have vision will say the chosen one was BS, and they will do their own. That means there may be routing protocol redistribution in the home. This would be a mistake.

Just pick one and hope (2) prevails. And we know from experience that whatever is chosen will be tweaked to adapt to new requirements or fix unanticipated problems.

Dino

> On Aug 5, 2015, at 10:26 AM, Ted Lemon <[email-masked]> wrote:
>

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 5 Aug 2015 16:54:57 -0400

> (2) Pick one and move on. This has a chance of working if open source is available because vendors will take the quick-approach into delivering a solution. We saw this work with SNMP in the 90s (bu…

Fortunately, in this case, there are open source implementations of both protocols that have been integrated with HNCP on OpenWRT.  So, we are likely to end up here if we pick one.

Regarding Ted's points about consensus:  I think the WG has pretty strong consensus to pick one.  There is a split amongst the WG regarding which one we prefer, but I think there might be many of us who would _accept_ either choice and think that was better than not picking one at all.

Margaret

---

From: [email-masked]
Date: Wed, 5 Aug 2015 14:00:50 -0700

> On Aug 5, 2015, at 1:54 PM, Margaret Cullen <[email-masked]> wrote:
> 

Wanting to pick one is not picking one. 

Vote or mandate. 

Dino

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Aug 2015 17:28:44 -0400

> Just pick one and hope (2) prevails. And we know from experience that whatever is chosen will be tweaked to adapt to new requirements or fix unanticipated problems.

I also prefer (2).   I suspect we disagree on which one to pick, but otherwise I agree that this is the right approach.

---

From: Margaret Cullen <[email-masked]>
Date: Wed, 5 Aug 2015 17:48:40 -0400

> Wanting to pick one is not picking one. 

I was for going with the design team recommendation, even though it was weak, because at least it was something…  Maybe if we are lucky a stronger recommendation will emerge?

It all depends on how much you care whether what we recommend is actually an IETF standard, and how much you care about performance on wi-fi transit links vs. security features or protocol maturity.  There is no way to do a direct comparison that will pick a winner, because different people care about different things.

Margaret

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 6 Aug 2015 08:45:09 +0200 (CEST)

On Thu, 6 Aug 2015, Glenn Parsons wrote:

> As I indicated in another thread, the right place to start a discussion on this would be in the IETF-IEEE 802 coordination that Dan leads.
>
> While this issue may be solved be current work underway (and included in the coordination), perhaps a clearer problem statement would help us to ensure that is the case.

There are documents that talk about multicast from a power efficiency 
standpoint:

https://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01
https://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00
https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-00

Slide 2 of 
http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf 
pretty much sums it up, most of IETF protocols are designed around 
multicast being as reliable as unicast. IPv6 relies on this. On 802.11 
this isn't the case. Slide 5 describes how this works in 802.11.

The fact that multicast and broadcast is unreliable (not ACKed) on 802.11 
is from what I can see the major cause of the unreliability problem that 
the mesh wifi networking protocols are trying to solve by basically only 
using multicast for discovery.

The whole question is whether this should be fixed by 802.11 or if the 
IETF needs to (basically) abandon multicast/unicast, or if the IETF should 
develop a multicast->unicast replication mechanism for wifi (there is work 
in this area going on).

Personally, I think 802.11 needs to fix multicast/unicast so it's 
reliable, or get back the IETF and say it can't be fixed and then the IETF 
can continue the work on multicast reduction (or workaround) even harder.

I find the current approach of (basically) individuals within the IETF 
working on multicast reduction without (as far as I can see) any dialogue 
with 802.11 to be a non-optimal way of solving the problems we're seeing.

---

From: Matthieu Boutier <[email-masked]>
Date: Thu, 6 Aug 2015 11:46:33 +0200

Hi Dino,

> Just be careful about the claim that DUAL is loop-free. It is loop-free because the toplogy stays in DUAL acitve-state until it is safe to change, but during that time, packets are black-holed.

Just to clarify: Babel doesn't use DUAL.  It uses the same feasibility condition, which gives the loop-free property, but uses another mechanism to solve starvation (which, by the way, is dead-lock free).  See [1], slides 9 and following.

[1] http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babel-20150723.pdf

Matthieu

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 06 Aug 2015 14:38:56 +0200

>> I would like to require the design team *to actually install the
>> software*.

Seconded.

> we cannot *require* IETF volunteers to put their own time

We can, however, politely request that they step down from the design team
unless they are willing to install and play with the software they're
evaluating.

> and money

Ray, I can get an OpenWRT-capable router at my local supermarket for €50.

> I can't even run the Homenet stack myself as my ISP doesn't yet have
> native IPv6

You should have tried.  Out of the box, the OpenWRT installation of hnetd
will generate a /48 ULA and a NATed IPv4 prefix, and use those for prefix
assignment.  You don't need an IPv6 upstream, just a DHCPv4 server to
trigger edge detection.

-- Juliusz

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 6 Aug 2015 08:54:53 -0400

> (1) Have homenet adopt both protocols. Let the market decide. That means there may be routing protocol redistribution in the home. This would be a mistake.
Would we not want to differentiate the option? Picking both now is not 
the same as either being available for use over time (perhaps that's a 
version of (2) below with a future option.

I am not sure why we are hung up on the notion that if we pick one now 
that it will be impossible to use a different protocol later (either 
exclusively or cooperatively).  This may not be the most ideal scenario 
(changing the options, or default later), but may be the most practical 
if we truly think there is future truth which will make one or the other 
protocol "seem" better later.

On that point, given I have no real bias either way, picking one (since 
it appears that both are viable) seems to be more important then having 
the (perceived) best protocol out of the gate -  but not making progress 
on any seems to be the bigger issue.  On my take on perceived,  given we 
have so little experience on how these protocols fare in the general 
case of homenet, many of the points made are quite theoretical (and at 
some point we just need real experience).

Many protocols seemed "great" until we actually used them, at which time 
we made adjustments to make it work better in real life (meaning real, 
non-lab, networks).

Personally, I don't think there will ever be the prefect protocol for 
this, just like there is no perfect protocol for any of the networks I 
ran (we have chosen, swapped, changed interior routing protocols over 
the years in the networks I worked with).  The homenet is not likely 
going to be the prefect specimen of a network model which will be the 
same everywhere.  I am sure there will be differences based on many 
factors - big one of which is the upstream operator.

 >(2) Pick one and move on. This has a chance of working if open source 
is available because vendors will take the quick-approach into 
 >delivering a solution. We saw this work with SNMP in the 90s (but this 
wasn’t an open-source case but a single reference implementation case).

 > (3) Pick one and hope it catches on. Vendors, if they have vision 
will say the chosen one was BS, and they will do their own. That means > 
there may be routing protocol redistribution in the home. This would be 
a mistake.

As to what may catch on, I would suspect the larger operators will have 
big say here.  They typically decide on what's on their networks and 
what gets pushed to the homes (not in all cases, but in many cases).  
Understanding where they are leaning should also be taken into 
consideration. Also, if they are leaning in different directions, that's 
also important.

So just to put myself in the line of fire now, it appears that we have 
had good progress on Babel (yeah I know the WG gap - but that can be 
fixed can't it?), but what technological reason is there which makes 
just going with this so problematic?  Had the case been the same for 
IS-IS for this use case profile, I would have stated the reverse.

regards,

Victor K

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 06 Aug 2015 15:02:38 +0200

> algorithm.

Babel does not use DUAL.

> It is loop-free because the toplogy stays in DUAL acitve-state until it
> is safe to change, but during that time, packets are black-holed.

Babel has no active state.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 6 Aug 2015 16:26:39 +0200 (CEST)

On Thu, 6 Aug 2015, Eric Gray wrote:

> It strikes me as something of a mistake generally to assume that multicast is as reliable as
> unicast.
>
> Unicast reliability depends on the mechanism(s) used to ensure reliability.  Unicast traffic
> tends to get lost every now and then.

Nobody doubts that packets get lost, but the general tendency since IP 
networking was invented, was that multicast delivery of packets wasn't 
especially worse than unicast. Packets get lost, but generally less than 
1% get lost, and multicast and unicast are affected equally.

> All the same factors that affect unicast packet delivery also affect 
> delivery of each packet with multicast.  Hence multicast reliability 
> should be worse than unicast reliability by an amount roughly 
> proportional to the amount of packet replication necessary to support 
> it.

Hm, care to elaborate? That seems a lot worse than my experience in 
deploying networks would tell me.

> Each replicated packet is as likely to be lost as any unicast packet. 
> Loss of one or more packets should be expected to be more likely with 
> multiple packets than with a single packet.

But it's still only a single packet per link.

> Multicast reliability, even when considered at the link level and 
> assuming replication is not required in transmission of multicast 
> packets onto the link itself, is only slightly better.  As full-duplex, 
> point-to-point connectivity becomes increasingly likely (fat yellow 
> cables are relatively rare any more), data replication still occurs - 
> just not at the level where a router sending packets onto the link is 
> likely to be aware of it.

Correct, as of 20 years ago or something we do not use 10base5 so L2 
devices do L2 replication.

> Hence it is interesting in this discussion that we are talking about an assumption that seems
> broken at the start.
>
> Have I missed something?

Well, 802.11 treats multicast (and broadcast) packets as a second rate 
citizen, I am not aware of any other L1/L2 technology that does this. 3GPP 
uses basically a point-to-point tunnel, so unicast and multicast is 
treated in very similar fashion without multicast being at a disadvantage.

So IETF needs to sit down and work out a strategy on how its protocols 
should work going forward, if everybody who designs protocols in the IETF 
should be told that multicast and broadcast "doesn't work properly", and 
act accordingly.

What probably needs to happen is that over time, the IETF should try to 
use less multicast, but on the other hand, 802.11 really needs to make 
sure that multicast works a lot better than it does today.

---

From: Glenn Parsons <[email-masked]>
Date: Thu, 6 Aug 2015 06:07:48 +0000

Cheers,
Glenn.

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, August 05, 2015 2:50 PM
To: Acee Lindem (acee)
Cc: Mikael Abrahamsson; Toerless Eckert (eckert); Homenet; Eric Gray; Glenn Parsons
Subject: Re: [homenet] Despair

Hi Acee,
Thanks for the extra context. Mikael forwarded me the email thread and I've started one off-list including Dan Romascanu, who is very responsive and helps coordinate and liaise with the IEEE.

I think we probably need a draft that describes the problems with reasonable detail first - and articulates the assumptions that are made on the link layer. That
will help make sure that we and the IEEE understand the issues involved.

Maybe that work can get coordinated with Mike McBride who's looking at this area for multicast protocols also.

Thanks,
Alia

On Wed, Aug 5, 2015 at 2:46 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Hi Mikael,

Thanks,
Acee

Regards,

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Aug 2015 07:47:17 +0000

Hi Mikael,

I agree that we need a more focused dialog. I am copying to your message the IEEE 802 - IETF coordination list. FYI - this is a team of IETF and IEEE 802 experts that includes but is not limited to the ADs who work on issues that require coordination between the IETF and the IEEE on the lines described by RFC 7241. Folks who are interested to join this activity - please write to me. You should also know Dorothy Stanley who is the liaison manager of IEEE 802.11 to the IETF. Let us see what other participants in IEEE 802 have to say about this before we discuss how we can best proceed. 

Regards,

Dan

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Thursday, August 06, 2015 9:45 AM
> To: Glenn Parsons
> Cc: Alia Atlas; Acee Lindem (acee); Toerless Eckert (eckert); Homenet; Eric
> Gray; Romascanu, Dan (Dan)
> Subject: RE: [homenet] Despair
> 
> > As I indicated in another thread, the right place to start a discussion on this
> would be in the IETF-IEEE 802 coordination that Dan leads.
> >
> > While this issue may be solved be current work underway (and included in
> the coordination), perhaps a clearer problem statement would help us to
> ensure that is the case.
> 
> pretty much sums it up, most of IETF protocols are designed around multicast
> being as reliable as unicast. IPv6 relies on this. On 802.11 this isn't the case.
> Slide 5 describes how this works in 802.11.
> 
> The fact that multicast and broadcast is unreliable (not ACKed) on 802.11 is
> from what I can see the major cause of the unreliability problem that the
> mesh wifi networking protocols are trying to solve by basically only using
> multicast for discovery.
> 
> The whole question is whether this should be fixed by 802.11 or if the IETF
> needs to (basically) abandon multicast/unicast, or if the IETF should develop
> a multicast->unicast replication mechanism for wifi (there is work in this area
> going on).
> 
> Personally, I think 802.11 needs to fix multicast/unicast so it's reliable, or get
> back the IETF and say it can't be fixed and then the IETF can continue the
> work on multicast reduction (or workaround) even harder.
> 
> I find the current approach of (basically) individuals within the IETF working
> on multicast reduction without (as far as I can see) any dialogue with 802.11
> to be a non-optimal way of solving the problems we're seeing.
> 
> --

---

From: Eric Gray <[email-masked]>
Date: Thu, 6 Aug 2015 12:31:13 +0000

All the same factors that affect unicast packet delivery also affect delivery of each packet
with multicast.  Hence multicast reliability should be worse than unicast reliability by an
amount roughly proportional to the amount of packet replication necessary to support it.

Each replicated packet is as likely to be lost as any unicast packet.  Loss of one or more
packets should be expected to be more likely with multiple packets than with a single
packet.

Multicast reliability, even when considered at the link level and assuming replication is not
required in transmission of multicast packets onto the link itself, is only slightly better.  As
full-duplex, point-to-point connectivity becomes increasingly likely (fat yellow cables are
relatively rare any more), data replication still occurs - just not at the level where a router
sending packets onto the link is likely to be aware of it.

Have I missed something?

--
Eric

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, August 06, 2015 2:45 AM
To: Glenn Parsons
Cc: Alia Atlas; Acee Lindem (acee); Toerless Eckert (eckert); Homenet; Eric Gray; Dan Romascanu ([email-masked])
Subject: RE: [homenet] Despair

Slide 2 of
http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf
pretty much sums it up, most of IETF protocols are designed around multicast being as reliable as unicast. IPv6 relies on this. On 802.11 this isn't the case. Slide 5 describes how this works in 802.11.

The fact that multicast and broadcast is unreliable (not ACKed) on 802.11 is from what I can see the major cause of the unreliability problem that the mesh wifi networking protocols are trying to solve by basically only using multicast for discovery.

The whole question is whether this should be fixed by 802.11 or if the IETF needs to (basically) abandon multicast/unicast, or if the IETF should develop a multicast->unicast replication mechanism for wifi (there is work in this area going on).

Personally, I think 802.11 needs to fix multicast/unicast so it's reliable, or get back the IETF and say it can't be fixed and then the IETF can continue the work on multicast reduction (or workaround) even harder.

I find the current approach of (basically) individuals within the IETF working on multicast reduction without (as far as I can see) any dialogue with 802.11 to be a non-optimal way of solving the problems we're seeing.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 6 Aug 2015 10:01:29 -0400

I think there are some problems with slide 5 of the references
presentation. Although I am active in IEEE 802.11 this is not
particularly my area of expertise. I'm sure Dorothy will correct me if
I'm wrong:

- The claim that the AP must retransmit multi-destination frames as
the "lowest possible" rate seems a bit misleading. Beacons (AP
originated station discovery frames) should be sent at the lowest rate
the AP is configured to use and Probes (station originated AP
discovery frames) should be sent with the lowest rate the station is
configured to use. Multi-destination data need only be sent at the
lowest rate needed for the worst of the associated stations, although
an AP could send slower if it wanted to, which still uses less air
time than serially unicasting since you would have to send it at that
slow rate anyway to that worst station. In any case, none of these is
the "lowest possible" rate, which I assume means the
slowest/most-robust modulation defined in the 802.11 standard.

- 802.11 does have a feature called GCR -- Groupcast With Retries,
which was part of the 802.11aa amendment, although it is not widely
implemented. It includes such features as a way for the AP to send
several multi-destination frames and then, using unicast, to poll
associated stations for a bit map of which of those frames they
correctly received (BlockAck) and a feature for the AP to
spontaneously transmit a multi-destination frame more than once
without causing confusion for improved reliability.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Thu, Aug 6, 2015 at 3:47 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
> ieee-ietf-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord

---

From: Dorothy Stanley <[email-masked]>
Date: Thu, 6 Aug 2015 14:55:13 +0000

Hi Dan,

Thanks for forwarding this.

a) I agree with Donald's comments below.

b) 802.11 also defines a Proxy Neighbor Discovery capability, and the mechanism for an AP to 
advertise that it provides this service. This is starting to be implemented (part of
Wi-Fi Alliance Passpoint certification) but is not widely deployed.

c) 802.11 defines a Directed Multicast service (multicast to unicast conversion). 
This is not widely implemented. 

d) Additionally, most if not all AP vendors implement multicast - unicast conversion and use it as they see the need for it.

e) This topic seems in need of a richer dialogue, possible steps include:
- develop a presentation describing the problem(s). http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast_issues-pptx.pdf is a start. 
- present in 802.11. The next 802.11 meeting is September 13-18 in Bangkok. 
Alternatively, we can set up a teleconference with 10 day notice.

Dorothy

-----Original Message-----
From: Donald Eastlake [mailto:[email-masked]] 
Sent: Thursday, August 06, 2015 7:01 AM
To: Romascanu, Dan (Dan)
Cc: Mikael Abrahamsson; Glenn Parsons; Toerless Eckert (eckert); Dorothy Stanley; [email-masked]; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

I think there are some problems with slide 5 of the references presentation. Although I am active in IEEE 802.11 this is not particularly my area of expertise. I'm sure Dorothy will correct me if I'm wrong:

- The claim that the AP must retransmit multi-destination frames as the "lowest possible" rate seems a bit misleading. Beacons (AP originated station discovery frames) should be sent at the lowest rate the AP is configured to use and Probes (station originated AP discovery frames) should be sent with the lowest rate the station is configured to use. Multi-destination data need only be sent at the lowest rate needed for the worst of the associated stations, although an AP could send slower if it wanted to, which still uses less air time than serially unicasting since you would have to send it at that slow rate anyway to that worst station. In any case, none of these is the "lowest possible" rate, which I assume means the slowest/most-robust modulation defined in the 802.11 standard.

- 802.11 does have a feature called GCR -- Groupcast With Retries, which was part of the 802.11aa amendment, although it is not widely implemented. It includes such features as a way for the AP to send several multi-destination frames and then, using unicast, to poll associated stations for a bit map of which of those frames they correctly received (BlockAck) and a feature for the AP to spontaneously transmit a multi-destination frame more than once without causing confusion for improved reliability.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA  [email-masked]

On Thu, Aug 6, 2015 at 3:47 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
>> Cc: Alia Atlas; Acee Lindem (acee); Toerless Eckert (eckert); 
>> Homenet; Eric Gray; Romascanu, Dan (Dan)
>> the coordination), perhaps a clearer problem statement would help us 
>> to ensure that is the case.
>>
>> http://www.ipv6council.be/IMG/pdf/20141212-08_vyncke_-_ipv6_multicast
>> _issues-pptx.pdf pretty much sums it up, most of IETF protocols are 
>> designed around multicast being as reliable as unicast. IPv6 relies 
>> on this. On 802.11 this isn't the case.
>> The fact that multicast and broadcast is unreliable (not ACKed) on 
>> 802.11 is from what I can see the major cause of the unreliability 
>> problem that the mesh wifi networking protocols are trying to solve 
>> by basically only using multicast for discovery.
>>
>> The whole question is whether this should be fixed by 802.11 or if 
>> the IETF needs to (basically) abandon multicast/unicast, or if the 
>> IETF should develop a multicast->unicast replication mechanism for 
>> wifi (there is work in this area going on).
>>
>> reliable, or get back the IETF and say it can't be fixed and then the 
>> IETF can continue the work on multicast reduction (or workaround) even harder.
>>
>> I find the current approach of (basically) individuals within the 
>> IETF working on multicast reduction without (as far as I can see) any 
>> dialogue with 802.11 to be a non-optimal way of solving the problems we're seeing.
>>
>> --

---

From: Eric Gray <[email-masked]>
Date: Thu, 6 Aug 2015 15:08:47 +0000

I wasn't aware of the treatment of multicast packets as less than best effort in
wireless transmission.  That is not exactly intuitive, given that radio is inherently 
broadcast.

Regarding relative loss probability, we may not be talking about the same thing.

I am referring to the increased probability of losing at least one packet when the
packets are replicated.

In the wired world, things that determine the probability of dropping one packet
(corruption, congestion, etc.) likely determine the probability of dropping others.

What I was saying is that - if there is a .0001 % chance of dropping a unicast packet, 
and (assuming the same probability for each multicast packet) a .0001 % chance of
dropping each of 3 replicated multicast packets, there is about a .0003 % probability 
of dropping at least one of the 3 multicast packets.

This is only an approximation because the probabilities are not precisely additive.
For values this small, however, it is a reasonably close approximation.

This might not be obvious in deployments, given the relatively small amount of real
multicast traffic and the very large amount of data that will need to be accumulated 
for this difference to be seen as more than statistical noise.

There is also the counting difficulty; in gathering the data, it would be necessary to
correlate multicast replications to determine the total probability for multicast loss
for the group.

Without this correlation, each multicast packet loss would have to be considered
independently of corresponding replicants.

It seems possible to me that you are referring to the probability of packet loss for
multicast packets independently of each other.  This, too, is not intuitive given that
losing any multicast packet in a multicast service represents a failure of the service.

--
Eric

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Thursday, August 06, 2015 10:27 AM
To: Eric Gray
Cc: Glenn Parsons; Alia Atlas; Acee Lindem (acee); Toerless Eckert (eckert); Homenet; Dan Romascanu ([email-masked])
Subject: RE: [homenet] Despair
Importance: High

On Thu, 6 Aug 2015, Eric Gray wrote:

> It strikes me as something of a mistake generally to assume that 
> multicast is as reliable as unicast.
>
> Unicast reliability depends on the mechanism(s) used to ensure 
> reliability.  Unicast traffic tends to get lost every now and then.

Nobody doubts that packets get lost, but the general tendency since IP networking was invented, was that multicast delivery of packets wasn't especially worse than unicast. Packets get lost, but generally less than 1% get lost, and multicast and unicast are affected equally.

> proportional to the amount of packet replication necessary to support 

Hm, care to elaborate? That seems a lot worse than my experience in deploying networks would tell me.

> packets onto the link itself, is only slightly better.  As 
> full-duplex, point-to-point connectivity becomes increasingly likely 
> (fat yellow cables are relatively rare any more), data replication 
> still occurs - just not at the level where a router sending packets 
> onto the link is likely to be aware of it.

Correct, as of 20 years ago or something we do not use 10base5 so L2 devices do L2 replication.

> Hence it is interesting in this discussion that we are talking about 
> an assumption that seems broken at the start.
>
> Have I missed something?

Well, 802.11 treats multicast (and broadcast) packets as a second rate citizen, I am not aware of any other L1/L2 technology that does this. 3GPP uses basically a point-to-point tunnel, so unicast and multicast is treated in very similar fashion without multicast being at a disadvantage.

So IETF needs to sit down and work out a strategy on how its protocols should work going forward, if everybody who designs protocols in the IETF should be told that multicast and broadcast "doesn't work properly", and act accordingly.

What probably needs to happen is that over time, the IETF should try to use less multicast, but on the other hand, 802.11 really needs to make sure that multicast works a lot better than it does today.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Aug 2015 15:29:02 +0000

I could not agree more.

It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet and then complain to IEEE that in fact it is not.

IPv6 over Ethernet makes heavy use of multicast over Ethernet, which for the lack of a highly scalable Multicast service always ends up broadcasted over the whole fabric.

When Wi-Fi is confused with Ethernet and the whole multi link becomes a single layer 2 fabric, we create a crisis that will not be solved by imputing the responsibility on the other SDO.

A solution was developed in IoT were even less multicast was acceptable. 

That solution builds a multi link subnet where the Ethernet fabric is a single L2 domain but packets are routed to the wireless edges so the multicast domain is effectively split.

The mechanism is simple and proven. The AP becomes a router and Wireless devices register their IP addresses to the router very much as a STA registers its MAC address at the association time. 

6LoWPAN ND (RFC 6775) is effectively a L3 association, which is indeed the appropriate mechanism for Wi-Fi.

Based on that registration, the AP/Router can proxy ND and filter unwanted multicast. 

We have running code for that proxy on Cisco IOS routers. It is derived from earlier (shipping, widely deployed) efforts that learn the registration by snooping, but that approach yields all sorts of issues and proprietary tricks.

My suggestion is to finally recognize that Wi-Fi is not Ethernet, in particular from the perspective of multicast, and provide the appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone router discussed above is one candidate solution.

Pascal

> Le 6 août 2015 à 16:26, Mikael Abrahamsson <[email-masked]> a écrit :
> 
>> All the same factors that affect unicast packet delivery also affect delivery of each packet with multicast.  Hence multicast reliability should be worse than unicast reliability by an amount roughly proportional to the amount of packet replication necessary to support it.
> 
>> Each replicated packet is as likely to be lost as any unicast packet. Loss of one or more packets should be expected to be more likely with multiple packets than with a single packet.
> 
>> Multicast reliability, even when considered at the link level and assuming replication is not required in transmission of multicast packets onto the link itself, is only slightly better.  As full-duplex, point-to-point connectivity becomes increasingly likely (fat yellow cables are relatively rare any more), data replication still occurs - just not at the level where a router sending packets onto the link is likely to be aware of it.
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 6 Aug 2015 09:12:59 -0700

> So just to put myself in the line of fire now, it appears that we have had good progress on Babel (yeah I know the WG gap - but that can be fixed can't it?), but what technological reason is there which makes just going with this so problematic?  Had the case been the same for IS-IS for this use case profile, I would have stated the reverse.

Okay, you make good points. I’ll start the voting.

I vote for Babel.

Dino

---

From: Gert Doering <[email-masked]>
Date: Thu, 6 Aug 2015 19:43:21 +0200

Hi,

> I vote for Babel.

+1

Gert Doering
        -- NetMaster

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Aug 2015 02:42:53 +0200

> I wasn't aware of the treatment of multicast packets as less than best
> effort in wireless transmission.  That is not exactly intuitive, given
> that radio is inherently broadcast.

Yes, that's counter-intuitive, but actually quite natural.

802.11 uses two different MAC sublayers: for unicast, it uses ARQ
(typically 8-persistent) and varies the PHY rate (depending on
e.g. pre-ARQ packet loss), while for multicast, it uses no ARQ and a fixed
PHY rate.

The effect is that unicast uses a higher data rate and virtually zero
packet loss, while multicast uses a low data rate and suffers from
significant packet loss (20% - 40% is not unusual for full-size frames,
and I've seen 80% on a link that was quite usable, post-ARQ, for reading
mail over IMAP).  This is good enough for IPv6 (both ND and RA use little
throughput and deal gracefully with reasonable packet loss), but makes
multicast useless for some other applications.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 08:21:35 +0200 (CEST)

On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote:

> It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet and 
> then complain to IEEE that in fact it is not.

This is an interesting viewpoint. IETF isn't "using wifi as if it was 
Ethernet". The customers who buy Wifi products buy it and run IP over it, 
expecting it should work (because that's what the advertising says). IP 
has been designed for wired ethernet (and Wifi carries ethernet frames). 
As far as I can tell, 802.11 never told the IETF that it wouldn't support 
multicast (really).

I'd say IETF isn't saying "IP works great over Wifi" (it doesn't really 
make any claims for any L1 or L2). However, I see producers of Wifi 
equipment saying that their products are great for using to connect to the 
Internet, which is saying "Wifi is great for IP".

> IPv6 over Ethernet makes heavy use of multicast over Ethernet, which for 
> the lack of a highly scalable Multicast service always ends up 
> broadcasted over the whole fabric.
>
> When Wi-Fi is confused with Ethernet and the whole multi link becomes a 
> single layer 2 fabric, we create a crisis that will not be solved by 
> imputing the responsibility on the other SDO.

Which is exactly why I said that both SDOs need to do something. However, 
since IP was "first" I think that 802.11 should have come to IETF a long 
time ago and said that it couldn't do multicast. Basically, what I 
interpret you're saying is that Wifi in its current form isn't suited to 
carry IP the way IP has been designed, for a long time. That would be news 
for a lot of people.

> My suggestion is to finally recognize that Wi-Fi is not Ethernet, in 
> particular from the perspective of multicast, and provide the 
> appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone 
> router discussed above is one candidate solution.

It's not only IPv6, but it's also IPv4 (since it uses broadcast, but less 
of it).

But what I hear here is that your opinion is that 802.11 doesn't need to 
change, but the IETF needs to change for IP to work over Wifi. I'd really 
appreciate some kind of official agreement from each SDOs who should do 
what. If the long-term technical solution is that the IETF should change 
L3 to basically avoid broadcast and multicast, then that's fine, as long 
as this is agreed upon by both parties.

However, I do think that 802.11 needs to point out to its members that if 
they don't implement assured multicast replication, IP doesn't work 
properly. Then they can decide what should be done in the short term, 
because changing IP will take quite a while.

---

From: Eric Gray <[email-masked]>
Date: Fri, 7 Aug 2015 06:56:14 +0000

Thanks!

-----Original Message-----
From: Juliusz Chroboczek [mailto:[email-masked]] 
Sent: Thursday, August 06, 2015 8:43 PM
To: Eric Gray
Cc: Homenet
Subject: Multicast in 802.11 [was: Despair]
Importance: High

802.11 uses two different MAC sublayers: for unicast, it uses ARQ (typically 8-persistent) and varies the PHY rate (depending on e.g. pre-ARQ packet loss), while for multicast, it uses no ARQ and a fixed PHY rate.

The effect is that unicast uses a higher data rate and virtually zero packet loss, while multicast uses a low data rate and suffers from significant packet loss (20% - 40% is not unusual for full-size frames, and I've seen 80% on a link that was quite usable, post-ARQ, for reading mail over IMAP).  This is good enough for IPv6 (both ND and RA use little throughput and deal gracefully with reasonable packet loss), but makes multicast useless for some other applications.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 09:02:29 +0200 (CEST)

On Thu, 6 Aug 2015, Dorothy Stanley wrote:

> d) Additionally, most if not all AP vendors implement multicast - 
> unicast conversion and use it as they see the need for it.

Just for clarification, do you mean "enterprise AP vendors" or do you 
really mean "most if not all AP vendors" across the entire range? Can you 
give an example of a sub-100USD residential consumer wifi-router/AP that 
implements this?

---

From: Teco Boot <[email-masked]>
Date: Fri, 7 Aug 2015 09:22:40 +0200

I remember non-transitive on faulty 10Base2. And lack of good multicast in FR and ATM.

There is a lot of IEEE802.11 stuff that works great for large scale WISP and enterprises, but is not available in open source or cheap home routers. At my WLC enabled home, I have most of the 802.11 optimizations on my WiFi infrastructure and on my mobile gear. It has other non-standardized optimizations, such as proxy-ARP.

On voting:
  IP on WiFi: +1 for RFC 5415 & 5416. 0 to -1 for TRILL, SDN and LISP (although these have my interest).
  RP: +1 for babel. Small, simple, cheap, does what is needed. IMHO there is no choice, IS-IS will not be adopted in the 10$ market.

So what I would like to see is CapWap support in OpenWRT, with HNCP for autoconfiguration.
And babel as replacement for the proprietary AP mesh protocols, also on enterprise class AP's.

Teco

> Op 7 aug. 2015, om 08:21 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
> 
> This is an interesting viewpoint. IETF isn't "using wifi as if it was Ethernet". The customers who buy Wifi products buy it and run IP over it, expecting it should work (because that's what the advertising says). IP has been designed for wired ethernet (and Wifi carries ethernet frames). As far as I can tell, 802.11 never told the IETF that it wouldn't support multicast (really).
> 
> I'd say IETF isn't saying "IP works great over Wifi" (it doesn't really make any claims for any L1 or L2). However, I see producers of Wifi equipment saying that their products are great for using to connect to the Internet, which is saying "Wifi is great for IP".
> 
> Which is exactly why I said that both SDOs need to do something. However, since IP was "first" I think that 802.11 should have come to IETF a long time ago and said that it couldn't do multicast. Basically, what I interpret you're saying is that Wifi in its current form isn't suited to carry IP the way IP has been designed, for a long time. That would be news for a lot of people.
> 
> It's not only IPv6, but it's also IPv4 (since it uses broadcast, but less of it).
> 
> But what I hear here is that your opinion is that 802.11 doesn't need to change, but the IETF needs to change for IP to work over Wifi. I'd really appreciate some kind of official agreement from each SDOs who should do what. If the long-term technical solution is that the IETF should change L3 to basically avoid broadcast and multicast, then that's fine, as long as this is agreed upon by both parties.
> 
> However, I do think that 802.11 needs to point out to its members that if they don't implement assured multicast replication, IP doesn't work properly. Then they can decide what should be done in the short term, because changing IP will take quite a while.
> 
> --

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Aug 2015 09:36:07 +0200

> properly.

That's an overstatement.  IPv6 works just fine over 802.11, it just
suffers from increased multicast packet loss and lower rate.  I don't
think there's anything in the IPv6 architecture that requires (link-local)
multicast performance to match unicast performance.

While it would be nice to have better multicast performance, I don't think
it's productive to be overly alarmist ("IPv6 obsolete before it gets
deployed, according to IETF spokesperson.  News at eleven.").

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Fri, 07 Aug 2015 09:36:34 +0200

>give an example of a sub-100USD residential consumer wifi-router/AP

OpenWrt does and we have kernel patches in our repo and have that enabled by default but I am not sure if vendors who fork us chose to dis- or enable it. So can't say if any off the shelve ones do out of the box.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 7 Aug 2015 10:08:33 +0200 (CEST)

>From what I heard in v6ops, it doesn't work well for larger settings like 
conferences, at least not without multicast reduction techniques.

So I'd say it suffers from the exact same problem as you've seen at 
battlemesh that multicast can't be used for anything else than discovery 
on platforms that don't implement multicast reduction/assured-delivery 
techniques.

> multicast performance to match unicast performance.

If you miss a few RAs in a row, you lose your default route and your 
prefix. With the tens of percent of packet loss you yourself mentioned, 
IPv6 doesn't work.

> While it would be nice to have better multicast performance, I don't 
> think it's productive to be overly alarmist ("IPv6 obsolete before it 
> gets deployed, according to IETF spokesperson.  News at eleven.").

I don't see how you can claim that ISIS can't use multicast on wifi 
because multicast on wifi doesn't work, but then next claim that IPv6 
multicast usage is fine.

Even though I haven't seen the multicast problem myself in my 15-20 years 
of using wifi for personal use, I thought I understood the problem well 
enough from the reports from the past few years, that I now fully support 
work that either reduces multicast on wifi to minimum, or work that will 
make multicast as reliable as unicast. Are you really now saying "it's not 
that bad" from your experience at battlemesh? How much IPv6 do you do at 
battlemesh anyway?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Aug 2015 10:21:40 +0200

> because multicast on wifi doesn't work,

I have never claimed that.  Babel uses multicast on wifi.  (Once again,
Mikael, I request that you stop misrepresenting my position.)

I think that the multicast reduction technique used by David in IS-IS and
by Markus in HNCP are a smart idea, and I intend to implement something
similar in a private branch of Babel in order to test how much of an
improvement it gives (the protocol explicitly allows that, so it's merely
an implementation change).  I won't merge it into the mainline until I get
a sufficient set of experimental data, which could take some time.

If you can publish your experimental data before then, that would be helpful.

-- Juliusz

---

From: "Hartog, F.T.H. (Frank) den" <[email-masked]>
Date: Fri, 7 Aug 2015 09:16:27 +0000

HGI is requesting Home Gateways to perform Wi-Fi multicast-to-unicast conversion, see http://www.homegatewayinitiative.org/publis/P_HGI01628R19.pdf . 

Regards, 

Frank
________________________________________
From: homenet [[email-masked]] on behalf of Juliusz Chroboczek [[email-masked]]
Sent: Friday, August 07, 2015 10:21 AM
To: Mikael Abrahamsson
Cc: Homenet
Subject: Re: [homenet] 802.11 is just fine for IPv6 [was: Despair]

-- Juliusz

_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

---

From: "Weil, Jason" <[email-masked]>
Date: Fri, 7 Aug 2015 10:44:12 -0400

Are you suggesting that IEEE and IETF send liaison letters to each other
when they begin crafting new protocols? This could possibly be useful
assuming anyone acted on it. The more likely scenario is for each SDO to
send an liaison saying ³Hey we just spent x years designing our new
protocol y, please take a look and see if your protocols both past and
present will function efficiently over it.²

In my experience there seems to be very little overlap between engineers
working in the IEEE and those working in the IETF. My company for example
has exactly zero overlap. IPv6 Multicast over IEEE 802.11 seems to be a
good example of how more interaction would be immensely useful early on in
the protocol development process. I¹m not sure there is a fix here, but it
would definitely be useful for both SDOs to keep in mind each others
protocols for interoperability purposes instead of just pointing to the
other to fix their protocols.

Customers

Jason

>because changing IP will take quite a while.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Aug 2015 04:14:06 +1200

On 08/08/2015 02:44, Weil, Jason wrote:
> when they begin crafting new protocols? 

Actually such a mechanism has existed for 15 years or so: the infamous
[email-masked] list, which I invented. It's a closed list (at this
point I forget why, but I imagine some SDOs have a complex about it)
populated by various liaisons. The theory was for SDOs to notify each
other about possibly overlapping new work in a more simple way than a
formal liaison statement. Because it's closed, I have no idea whether
there's any recent traffic.

> This could possibly be useful

... with a P.S. apologising for having forgotten to mention it x years
ago on the new-work list. Yes, that's exactly what has happened before
now.

    Brian

---

From: Dorothy Stanley <[email-masked]>
Date: Fri, 7 Aug 2015 17:24:35 +0000

I meant "enterprise AP vendors". 

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Friday, August 07, 2015 12:02 AM
To: Dorothy Stanley
Cc: Donald Eastlake; Romascanu, Dan (Dan); Glenn Parsons; Toerless Eckert (eckert); [email-masked]; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray
Subject: RE: [ieee-ietf-coord] [homenet] Despair

> unicast conversion and use it as they see the need for it.

Just for clarification, do you mean "enterprise AP vendors" or do you really mean "most if not all AP vendors" across the entire range? Can you give an example of a sub-100USD residential consumer wifi-router/AP that implements this?

---

From: Alia Atlas <[email-masked]>
Date: Fri, 7 Aug 2015 15:49:35 -0400

[email-masked] is alive & used for coordination and information.  We
also coordinate specifically with the IEEE on items of mutual interest
several times a year.
On Aug 7, 2015 12:13 PM, "Brian E Carpenter" <[email-masked]>
wrote:

> > This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
> >

---

From: Geoff Thompson <[email-masked]>
Date: Fri, 7 Aug 2015 11:09:25 -0700

What you are suggesting here is heresy.
You are saying that the basic assumption made 35 years ago,
Layering,
doesn't work.
What a surprise.
It is not only true for WiFi,
we are confronting the same problem with higher layers and applications wanting to send/receive precise timing information over the network and that capability not being supported by Ethernet.

The bottom line is that the layering that was defined so many years ago by the pioneers was imperfect.
In particular, it was highly imperfect in putting forth what was not defined in the layering model that we all have used (MoL).
It is no surprise (to me, at least) that we are running into trouble as IP over 802 is now being called upon to take over the entire communications space that was formerly occupied by the switched and decimated low-noise, low-loss links of the hard-wired and legacy telephony networks.

To that end, it has never been clear to me that you can effectively use a screwdriver to pound nails.

Geoff Thompson
"The wishes of Marketing have remarkably little to do with the laws of Physics"

> On Aug 7, 2015, at 7:44 AMPDT, Weil, Jason <[email-masked]> wrote:
>

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Sat, 8 Aug 2015 00:07:33 +0000

No one is saying that 802.11 can't do multicast. It does do multicast, but with more loss than the protocols sending multicast may assume or be able to accommodate. As I understand the presentation that kicked off this discussion, this becomes an issue since IPv6 relies more on multicast.  While IP came first, IPv6 didn't.  

Increasing use of low power devices that have times when they "sleep" and therefore miss multicasts contributes to the problem. But low power use for battery or low-energy source based devices is essential. It isn't going away. (Wired devices sleep to save energy too but they are generally less power constrained so they are able to go into a less deep sleep and can wake to receive traffic.)  And even when wireless devices don't sleep, they experience varying connectivity due to movement.

Pointing fingers isn't going to help this. We need to get together and see what can be done to improve the situation. 

Regards,
Pat

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Aug 2015 02:24:13 +0200

> As I understand the presentation that kicked off this discussion, this
> becomes an issue since IPv6 relies more on multicast.

I may be confused, but I was under the impression that IPv6 uses multicast
(ND, RA) in the exact same places where IPv4 uses broadcast (ARP, DHCPv4).
As far as the 802.11 MAC is concerned, broadcast and multicast are treated
the same, so 802.11 should be just as suitable or unsuitable for IPv6 as
for IPv4.

-- Juliusz

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 8 Aug 2015 07:32:21 +0200 (CEST)

On Sat, 8 Aug 2015, Pat (Patricia) Thaler wrote:

> No one is saying that 802.11 can't do multicast. It does do multicast, 
> but with more loss than the protocols sending multicast may assume or be 
> able to accommodate. As I understand the presentation that kicked off 
> this discussion, this becomes an issue since IPv6 relies more on 
> multicast.  While IP came first, IPv6 didn't.

Not only IPv6, but a lot of other protocols as well such as routing 
protocols, and content carried over multicast transport.

And well, I'd venture to say that basic 802.11 doesn't do multicast in any 
true sense of the word, I have yet to hear about anyone using 802.11 for 
instance for multicast IP video streaming. People have tried, quickly 
discovered it didn't work (for any sensible level of work, multiple 
percent packet loss doesn't count as "work" in a packet data network), and 
moved to wires instead.

> Increasing use of low power devices that have times when they "sleep" 
> and therefore miss multicasts contributes to the problem. But low power 
> use for battery or low-energy source based devices is essential. It 
> isn't going away. (Wired devices sleep to save energy too but they are 
> generally less power constrained so they are able to go into a less deep 
> sleep and can wake to receive traffic.)  And even when wireless devices 
> don't sleep, they experience varying connectivity due to movement.
>
> Pointing fingers isn't going to help this. We need to get together and 
> see what can be done to improve the situation.

Sounds good to me. I just want things to be clear to everybody since there 
is obviously a significant crowd here in the IETF that thinks multicast 
will work just fine on "all" packet transports. So 802.11 and IETF needs 
to figure out who should do what, either IETF needs to do less multicast 
in its protocols, or a workaround needs to be created to handle wifi 
networks so multicast works (done by the IETF), or 802.11 needs to fix so 
unicast and multicast works very much the same on 802.11 and then IETF 
doesn't need to change much, at least not for existing protocols.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 8 Aug 2015 07:46:06 +0200 (CEST)

> the same, so 802.11 should be just as suitable or unsuitable for IPv6 as

You are correct, so this is a problem for IPv4 as well.

It's just that comparing the amount of ARP broadcast packets seen in an 
IPv4 network and the amount of RA/ND packets seen in an IPv6 network, I'd 
imagine the amount of multicast for IPv6 is more than 10x (just guessing) 
larger unless mitigation is put in place, and then it's just larger, not 
magnitudes larger.

If you miss a couple of consecutive RAs in IPv6, you abandon your prefix 
and your default route. A host talking to its IPv4 gateway that has 
received its address using for instance DHCPv4, usually doesn't have to do 
any multicast/broadcast for hours as long as it keeps talking to/through 
the gateway.

So IPv6 is a lot more sensitive to multicast packet loss compared to IPv4.

When IPv6 was designed around 1995 multicast was thought to be more 
effective (because it was a middle ground between broadcast and unicast, 
giving a decent tradeoff between sending to all and sending multiple 
packets to whoever might be interested) compared to IPv4. This is still 
now 20 years later a mindset seen widely throughout the IETF because 
nobody (as far as I know) has clearly said otherwise.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Aug 2015 13:36:59 +0200

> What you are suggesting here is heresy.  You are saying that the basic
> assumption made 35 years ago, Layering, doesn't work.  What a surprise.

No.  What this says is that strict layering has a performance cost, and
a way to recover some of this performance is to organise carefully
controlled leaks between the layers.  (You're already doing that -- your
layer 3 routing protocol is probably aware of physical carrier sense.)

The success of the (reasonably well layered) TCP/IP suite would indicate
that the market has decided that this is a cost well worth paying.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 08 Aug 2015 16:00:37 +0200

> I'd imagine the amount of multicast for IPv6 is more than 10x (just
> guessing) larger unless mitigation is put in place,

I'm perhaps confused, but I don't see why.  ARP is somewhat loosely
specified, so it's difficult to say for sure without checking the
implementations, but I'd expect ND to be just as efficient as ARP.

> and your default route.

I'm confused again.  PIO lifetimes are on the order of hours, or even
days, while unsolicited RAs are sent every 60s.  Plus there's nothing
preventing you from sending them more often.

-- Juliusz

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Sat, 8 Aug 2015 00:24:03 +0000

As Alia points out, because of increasing areas where there was overlap between our work, we started coordinating more closely a few years ago.  We maintain a list of areas that we have identified as benefiting from  coordination.

We have teleconference meetings 3 times a year which include a discussion of new work for both groups. Rather than sending liaison letters back and forth, this gives the opportunity to have a brief discussion about what the new work is and whether it is something that should be added to the coordination list.

We also have the ieee-ietf-coord mailing list to discuss issues or new topics as they arise.

Regards,
Pat

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Friday, August 07, 2015 12:50 PM
To: Brian E Carpenter
Cc: Pascal Thubert (pthubert); Toerless Eckert (eckert); [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; Weil, Jason; Homenet; Eric Gray; Acee Lindem (acee); Mikael Abrahamsson
Subject: Re: [ieee-ietf-coord] New work in other SDOs [was Despair]

[email-masked]<mailto:[email-masked]> is alive & used for coordination and information.  We also coordinate specifically with the IEEE on items of mutual interest several times a year.
On Aug 7, 2015 12:13 PM, "Brian E Carpenter" <[email-masked]<mailto:[email-masked]>> wrote:

[email-masked]<mailto:[email-masked]> list, which I invented. It's a closed list (at this

    Brian

> On 8/7/15, 2:21 AM, "Mikael Abrahamsson" <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 8 Aug 2015 16:22:12 +0000

Mikael is correct;

IPv6 mechanisms are different.

SLAAC adds broadcasts that are not present in IPv4, MLD report then NS DAD then, sometimes and though it is not required by the spec, NA(O).

IPv6 nodes tend to create multiple addresses, many of which are temporary for privacy reasons. So the above happens again and again.

Finally the emergence of smaller hosts like phones have changed the average mobility profile of devices, making things even worse. Devices may for instance broadcast an RS, form new addresses and/or DAD again after a movement or a sleep period.

With classical ND Wireless devices shoot themselves in the foot, and the more they move and the larger the subnet, the worst they make the situation for one another.

The association process that Wi-Fi uses at layer 2 is more appropriate. It is also appropriate for sleeping devices as Pat discussed, since the registration can request sleeping proxy operations from the router.

Cheers,

Pascal

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 8 Aug 2015 21:52:50 +0200 (CEST)

> preventing you from sending them more often.

Andrew Yourtchenko is a lot better than I am at explaining this:

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76326
http://d2zmdbbm9feqrf.cloudfront.net/2014/eur/pdf/BRKEWN-2666.pdf

So you haven't seen any IPv6 related problems in your battlemesh testing? 
I just find it strange that you have hit the multicast problem for routing 
protocols but not for IPv6.

---

From: Geoff Thompson <[email-masked]>
Date: Sat, 8 Aug 2015 14:04:12 -0700

> On Aug 8, 2015, at 4:36 AMPDT, Juliusz Chroboczek <[email-masked]> wrote:
> 

Not that I ever heard of.
First of all, "carrier sense" was quite intermittent and indicative of nothing more than whether or not you could transmit in the CSMA/CD Ethernet that was dominant until the mid 90's.
but that information doesn't carry across layer 2 bridges/switches.
After the mid 90's Ethernet repeaters were displaced by switches in layer 2 networks, many of which are fairly large.  Carrier sense at the edge of the network where it interfaces with a layer 3 device is meaningless with respect to the layer 2 network as a whole.
> that the market has decided that this is a cost well worth paying.

Precisely my point, except that it is not true.  The datagram service that was provided for with such "success" by TCP/IP does not provide the same service over all physical layers.  In fact the now predominant physical layers do not provide sufficiently low-jitter, low loss service for all legacy services to work well.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 09 Aug 2015 20:19:32 +1200

On 09/08/2015 09:04, Geoff Thompson wrote:

...
> Precisely my point, except that it is not true.  The datagram service that was provided for with such "success" by TCP/IP does not provide the same service over all physical layers.  In fact the no…

You mean, sufficient compared with 4800 baud modems over spotty analogue
phone lines, which were predominant when those legacy apps, right up
to HTTP/1.0, were invented?

What don't work well are *modern* services invented for broadband, in
the absence of anything accurately described as broadband.

But, yes, I hope the final list of requirements for the homenet routing
protocol includes: works adequately on lossy wireless media with poor
multicast support.

    Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 09 Aug 2015 21:02:28 +0200

> protocols but not for IPv6.

Ah, I now understand that we were speaking about different things.

The issue that Babel used to have with 802.11 multicast was not packet
loss -- Babel is designed to be extremely resilient to packet loss, it
handles 80% loss before breakfast.

The issue was about collisions.  802.11 uses CSMA/CA, which is not as good
at avoiding collisions as the familiar CSMA/CD (which cannot be used on
wireless).  Since multicast packets are sent at a glacially slow rate,
multiple nodes multicasting simultaneously can cause the network to
collapse.

In earlier days, engineers from a company that wishes to remain anonymous
were testing Babel by putting 1500 mesh routers, tuned to a single
frequency, in a room, and booting them all simultaneously.  They found
that when doing that Babel would cause massive amounts of collisions for
no less than 20 minutes; the network worked fine once the bootstrap had
finished.

The issue was fixed by doing two things: rate-limiting replies to wildcard
requests and adding massive amounts of jitter to "urgent" TLVs (those that
the spec says "MUST be sent in a timely manner").  Of course, this
increases convergence time on wired networks, but something had to give.

There are two lessons to be drawn from that experience:

  1. don't put 1500 wifi routers in a single room;

  2. making a routing daemon that works well in a variety of conditions is
     hard work, and requires large amounts of careful testing.

But please don't take my word for it -- it would be way more helpful if
you could do your own testing in order to find out how well IS-IS works
over wireless, and publish your experimental results.  As far as I am
aware, nobody has done that, so this would be a seminal paper in its
(admittedly narrow) niche.

-- Juliusz

---

From: Geoff Thompson <[email-masked]>
Date: Sun, 9 Aug 2015 11:39:14 -0700

Brian-

> On Aug 9, 2015, at 1:19 AMPDT, Brian E Carpenter <[email-masked]> wrote:
> 

Actually, I do. 
First of all, it wasn't that spotty in terms of errors per hour (which is what you need to count to factor out data inflation)
and it had a number of secondary characteristics that weren't taken into account in formulating the layered model.

> the absence of anything accurately described as broadband.

Not really. Communicating time information works much better in a real-time circuit switched network than it does in a packet based store and forward network.

> protocol includes: works adequately on lossy wireless media with poor

Geoff

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 16:02:21 +0900

On Mon, Aug 10, 2015 at 4:02 AM, Juliusz Chroboczek <
[email-masked]> wrote:

> [...]

What he said.

How do we communicate this to the design team?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 09:32:06 +0200 (CEST)

On Mon, 10 Aug 2015, Stephens, Adrian P wrote:

> The question in my mind is whether this discussion thread is uncovering any new requirements for the 802.11 standard.

Thanks for the summary, it seems correct.

It might not need new 802.11 standards, but we still have an operational 
problem in that it seems some of these standards are not universally 
implemented by 802.11 based device vendors.

IETF standards generally assume that multicast and unicast are delivered 
with a similar level of packetloss (which is low).

Not all 802.11 implementations have the multicast ACK mechanism 
implemented, thus it would seem that multicast will be less likely to get 
delivered to the recipient over these 802.11 implementations.

For me, it seems these 802.11 broadcast/multicast ACK functions should be 
"mandatory" to implement if the device wants to support IPv4 and IPv6 
networks.

How do we achieve this?

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 05:50:11 +0000

Hello all,

Let me summarise some of the characteristics of the 802.11 standard related to multicast:
1.  The basic "packet error rate" (before Ack) designed to is 10% in the case of unicast.   This is a very broad statement and almost so
simplistic as to be misleading.    Errors are composed of 1) collisions, 2) interference,  3) rate/MCS adaptation
errors,  4) sudden changes in the radio environment such as shadowing.   The residual error for unicast is less because of the retry mechanism.

2. Multicast is generally sent at a  low "basic" (one intended to be receivable by all STAs in the AP's network) rate.   This improves reliability in some of the error causes cited above, but not all. 

3. Multicast is generally not acknowledged.

4. Multicast may be buffered when power-savers are present.  An AP may discard buffered traffic due to internal resource constraints.  Buffered multicast traffic is generally delivered once per DTIM,  which is a configurable multiple of the beacon interval.
Note that the asymmetry of the buffering times might cause an AP to discard more buffered multicast traffic than unicast.  Whether it does is something I don't know,  I'm just mentioning it as a possibility.

5. When multicast is delivered using the DTIM mechanism,   a whole sequence of buffered multicast frames are transmitted using a "SIFS" gap (i.e. uninterruptable).   This reduces the probability of individual packet collision from nearby STAs.

6. The STAs associated with an AP may exhibit different reliabilities receiving multicast traffic.   Those on the edge of the AP's network will receive at lower power.  More subtly,  they may be closer to 802.11 interferers that cannot receive from the AP,  and therefore do not honour any of the protection mechanisms that might be used by the AP.

The bottom line of operating in an unlicensed medium is that nothing is predictable and there are absolutely no guarantees.

The standard contains mechanisms to improve the reliability of multicast and remove it from the DTIM buffering mechanism.

Implementations can do a multicast to unicast translation.  The standard does not support this,  but it does not prevent
it either.

The question in my mind is whether this discussion thread is uncovering any new requirements for the 802.11 standard.
I can make time on the 802.11 meeting agenda to discuss the topic.   Dorothy Stanley is 802.11's liaison to IETF,  so if folks did
want to contribute to a discussion document,  I suggest they work with her.   Our next meeting is September 13-18.
(http://www.ieee802.org/11/Meetings/Meeting_Plan.html)

Yours sincerely,
 
Adrian P STEPHENS
Chair, IEEE 802.11 Working Group
 
Tel: +44 (1793) 404825 (office)
 
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Pat (Patricia) Thaler
Sent: 08 August 2015 01:08
To: Mikael Abrahamsson; Pascal Thubert (pthubert)
Cc: Toerless Eckert (eckert); [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

Regards,
Pat

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Thursday, August 06, 2015 11:22 PM
To: Pascal Thubert (pthubert)
Cc: Toerless Eckert (eckert); Alia Atlas; Dan Romascanu ([email-masked]); Glenn Parsons; Homenet; [email-masked]; Acee Lindem (acee); Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote:

> It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet 
> and then complain to IEEE that in fact it is not.

This is an interesting viewpoint. IETF isn't "using wifi as if it was Ethernet". The customers who buy Wifi products buy it and run IP over it, expecting it should work (because that's what the advertising says). IP has been designed for wired ethernet (and Wifi carries ethernet frames). 
As far as I can tell, 802.11 never told the IETF that it wouldn't support multicast (really).

> IPv6 over Ethernet makes heavy use of multicast over Ethernet, which 
> for the lack of a highly scalable Multicast service always ends up 
> When Wi-Fi is confused with Ethernet and the whole multi link becomes 
> a single layer 2 fabric, we create a crisis that will not be solved by 

But what I hear here is that your opinion is that 802.11 doesn't need to change, but the IETF needs to change for IP to work over Wifi. I'd really appreciate some kind of official agreement from each SDOs who should do what. If the long-term technical solution is that the IETF should change
L3 to basically avoid broadcast and multicast, then that's fine, as long as this is agreed upon by both parties.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 17:02:32 +0900

> preventing you from sending them more often.

The default is 600s, not 60s. And router lifetimes are much shorter than
PIO lifetimes. The field is only 16 bits, the "maximum" (MUST NOT send
more, MUST accept any 16-bit value) is 9000, and the default is 1800.

The RFC 4861 defaults (max interval = lifetime / 3, min interval = max
interval / 3, uniform distribution) equate to one RA every 0.22 lifetimes,
or 4.5 RAs per lifetime. If packet loss is 50%, then you'll miss 4 RAs
6.25% of the time.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 17:04:08 +0900

We also need to remember that from the perspective of battery-operated
devices, multicast is attractive because it's cheaper to receive
unacknowledged multicast than to receive acknowledged unicast (which
requires the hardware to transmit).

On Sat, Aug 8, 2015 at 9:07 AM, Pat (Patricia) Thaler <[email-masked]>
wrote:

> No one is saying that 802.11 can't do multicast. It does do multicast, but
> with more loss than the protocols sending multicast may assume or be able
> to accommodate. As I understand the presentation that kicked off this
> discussion, this becomes an issue since IPv6 relies more on multicast.
> While IP came first, IPv6 didn't.
>
> Increasing use of low power devices that have times when they "sleep" and
> therefore miss multicasts contributes to the problem. But low power use for
> battery or low-energy source based devices is essential. It isn't going
> away. (Wired devices sleep to save energy too but they are generally less
> power constrained so they are able to go into a less deep sleep and can
> wake to receive traffic.)  And even when wireless devices don't sleep, they
> experience varying connectivity due to movement.
>
> Pointing fingers isn't going to help this. We need to get together and see
> what can be done to improve the situation.
>
> Regards,
> Pat
>
> Cc: Toerless Eckert (eckert); Alia Atlas; Dan Romascanu (
> [email-masked]); Glenn Parsons; Homenet; [email-masked];
> Acee Lindem (acee); Eric Gray

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 10:28:15 +0200

On Mon, Aug 10, 2015 at 9:32 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Not all 802.11 implementations have the multicast ACK mechanism implemented,
> thus it would seem that multicast will be less likely to get delivered to
> the recipient over these 802.11 implementations.
>

Excuse me, multicast ACKs on 802.11?

I know that some implementations/stacks split up multicast into
several unicasts (which will then be acked and will have
retransmissions), but I have yet to hear about multicast ACKs in the
IEEE 802.11 standard.

Henning Rogge

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 01:33:36 -0700

IMHO, a better place for this discussion than homenet is Mboned,
for example in conjunction with evolving draft-mcbride-mboned-wifi-mcast-problem-statement.

I do not particularily like the scope either of the discussion in homenet
or in the draft in MBoned, because both only look at the problems, not
the opportunities/benefits. If we stay that line of thought, it will just
lead to further removal of multicast. Multicast is necessary for
discovery, it is necessary for most efficient airtime use in multipoint
delivery and it is the most flexible multipoint deliver API we've come 
up with so far in the IETF. It is not necessarily equally beneficial 
for a bunch of signaling procedures where we've  been using it so far
in wired LANs. Especially in IPv6 signaling.

The IPv6 and routing protocol signaling use of IP multicast are IMHO
most easy to solve because they really don't need a serious amount of
airtime when done right. And it would be lovely if not every routing
protocol would have to come up with its own scheme but if we could define
an appropriate set of procedures ONCE that all protocols we want to use
could plug into equally. Babel, IS-IS, RPL, what have you. I think
ISO called this subnet adaptation layer ;-)) We (IETF) did this for some
other technologies if i remember correctly. And IMHO it also applies
to non-multicast issues in WiFi.

What would be cool, but where i see little hope to do something useful
unless the IEEE actually helps us to prioritize the use-cases is to
automatically do protected (reliable)  multicast vs. replicated-unicast
streaming of multipoint data via WiFi. And its easy to see when one
approach is better than the other (based on #receivers and per-receiver
channel characteristics). It just takes a lot of WiFi specific logic
to make the right choice.

Cheers
    toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 10:34:06 +0200 (CEST)

> retransmissions), but I have yet to hear about multicast ACKs in the

Donald Eastlake posted this a few days ago:

"- 802.11 does have a feature called GCR -- Groupcast With Retries,
which was part of the 802.11aa amendment, although it is not widely
implemented. It includes such features as a way for the AP to send
several multi-destination frames and then, using unicast, to poll
associated stations for a bit map of which of those frames they
correctly received (BlockAck) and a feature for the AP to
spontaneously transmit a multi-destination frame more than once
without causing confusion for improved reliability."

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 17:35:16 +0900

On Fri, Aug 7, 2015 at 6:16 PM, Hartog, F.T.H. (Frank) den <
[email-masked]> wrote:

> HGI is requesting Home Gateways to perform Wi-Fi multicast-to-unicast
> conversion, see
> http://www.homegatewayinitiative.org/publis/P_HGI01628R19.pdf .
>

That seems like a bad idea, at least for ICMPv6 multicast, because it is
known to impact battery life.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 10:42:40 +0200

> without causing confusion for improved reliability."

Okay...

this is quite new and I am not sure it will solve all the multicast
problems for 802.11. Neighbor discovery (both IPv6 and routing
protocol) has potentially to deal with a lot of neighbors, some of
them not even known to the transmitter. It also feels like a lot of
consumed airtime to replace a multicast with a multicast and one
unicast for each known neighbor. This could be dozens of media
accesses.

Henning Rogge

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 08:43:07 +0000

Hello Mikael,

" For me, it seems these 802.11 broadcast/multicast ACK functions should be "mandatory" to implement if the device wants to support IPv4 and IPv6 networks.

How do we achieve this?"

There are two routes to "mandatory".   The standard can indicate something is mandatory if you support
a particular feature. 

The second is certification.  This is the not-so-simple task of persuading a sufficient number of WiFi-Alliance members
that it is in their economic interest to support the feature that a certification program can be created.   Even, given a 
certification,  the market will still decide whether that is relevant or not.

Best Regards,
 
Adrian P STEPHENS
 
Tel: +44 (1793) 404825 (office)
Tel: +1 (971) 330 6025 (mobile)

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 08:32
To: Stephens, Adrian P
Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; Homenet; Eric Gray
Subject: Re: [ieee-ietf-coord] [homenet] Despair

It might not need new 802.11 standards, but we still have an operational problem in that it seems some of these standards are not universally implemented by 802.11 based device vendors.

IETF standards generally assume that multicast and unicast are delivered with a similar level of packetloss (which is low).

Not all 802.11 implementations have the multicast ACK mechanism implemented, thus it would seem that multicast will be less likely to get delivered to the recipient over these 802.11 implementations.

For me, it seems these 802.11 broadcast/multicast ACK functions should be "mandatory" to implement if the device wants to support IPv4 and IPv6 networks.

How do we achieve this?

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 01:49:31 -0700

Hmm... the multicast to unicast conversion described in there looks fairly
weak. It doesn't discuss any problems with IGMPv2/MLDv1 wrt to report
suppression and how to deal with that for example. Or the challenge that
hosts may not be happy about receiving IP multicast packets with unicast MAC
destination address. If an organization has the ability to specify behavior
f HNID's (as in 5.2), then it would be a lot better to specify those
refinemenet (eg: translate back to L2-multicast in downstream HNID's, L2 unicast
IGMp queries to inhibit report suppression o proxy into IGMPv3/MLDv2, etc. pp.)

What interaction does IETF have with that initiative ? 
Does it make sense / is it possible to engage with these folks ?
Anybody hee workin over there ?

Seems they are planning to be gone anyhow, so just likley the will create from existing
docs some half-baked solution ?

http://www.homegatewayinitiative.org/news/PressReleases/PR11_HGI_Conclusion_FINAL.pdf

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 02:15:20 -0700

This is a nice start for what i'd call poblem 2): making
multipoint delivery of serious amount of data to more receivers more
reliable.  Would love to understand if there is any definition of how
this would or could be used for actual IP multicast, eg: where
is the definition of using IGMP membership reports to
track receivers, automatically define a GCR etc. pp ?? I'd be surprised
if 802.11 would elevate to that level... Maybe thats something we could/should do ?

But yes, this is not solution to problem 1) which is about IP signaling
protocols that currently rely on multicast. We should target something
that has a lower set of requirements against APs (like worst possible AP
needs to work for us), and we probably want to take more care of
battery. (I say probably because i still haven't seen good simple but persuasive
numbers for wifi-multicast vs. real world batery drain, so i am operation on a
faith base only here which i don't particularily like. )

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 11:26:49 +0200 (CEST)

(included [email-masked] and also changed subject to something more 
appropriate)

As far as I can tell, so far people have told IETF it's their job to 
reduce multicast to make IP based protocol "work" on 802.11 media. That's 
at least what I have been seeing. Considering the reactions from other 
parties, it seems the "multicast sucks on 802.11" is something 802.11 
hasn't heard of before.

The only thing IETF can do is to use less multicast, and the obvious way 
of solving it is to just replicate into unicast. This seems like a 
suboptimal way to work around the problem if there are a lot of nodes.

>From what I read below, one way out of this is the IETF making a clear 
statement that multicast is an integral part of IP networking, and if a 
medium doesn't support delivering multicast frames in a similarily 
reliable fashion to unicast, it's not suited to carrying IP based 
protocols (or any other protocol that uses L2 broadcast/multicast).

It seems to me that there are a few paths that the IETF could go:

Write an RFC stating requirements on L1/L2 protocols when it comes to 
unicast, multicast and broadcast handling of packets. This could include 
options for mechanisms that turned multicast/broadcast into unicast that 
certain medias could have as requirements. Then IEEE could create a device 
profile that would fulfil these requirements, possibly add a 
certification, and then try to get market pressure to require devices to 
support this profile. The IETF wouldn't change its mind about how 
multicast is used in its protocols after this, but just say "this is the 
reality, please deal with it when you create L1/L2 that's supposed to 
carry IP".

Or the IETF could just say that this seems like a lost cause, 
multicast/broadcast doesn't seem to work on some L1/L2, and start working 
on techniques that minimizes broadcast/multicast and change all the 
protocols to reflect this new reality.

Something in the middle, but anyway changing the requirements on IETF 
protocols to avoid using multicast if it can, documenting where it makes 
sense and when it doesn't.

Right now what I am seeing is that there are people who are lobbying to do 
away with multicast as much as possible because they see that in reality 
it's not reliable on the devices they have tested it on.

What are the odds that 802.11 could agree on a device profile for "IP use" 
that would include reliable multicast delivery, and one that there is 
reasonable belief that this would gain significant market adoption?

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 10 Aug 2015 18:33:01 +0900

Sure, but for small packets, it's pretty unlikely that unicast would be
cheaper. An RA will likely only be 100 or 200 bytes.

On Mon, Aug 10, 2015 at 6:30 PM, Stephens, Adrian P <
[email-masked]> wrote:

> Hello all,
>
>
>
> “it's cheaper to receive unacknowledged multicast than to receive
> acknowledged unicast (which requires the hardware to transmit)”
>
> I’m afraid this is not necessarily so.
>
> The rate at which multicast is sent is usually a “basic” rate – such as 24
> Mbps.
>
> The rate at which unicast is received might be 250 Mbps.   So, depending
> on the length of data,  and the relative
>
> platform power consumptions of tx vs rx vs idle vs asleep,  unicast may or
> may not be a lower power consumption.
>
>
>
> Best Regards,
>
>
>
> Adrian P STEPHENS
>
>
>
> *From:* ieee-ietf-coord [mailto:[email-masked]] *On
> Behalf Of *Lorenzo Colitti
> *Sent:* 10 August 2015 09:04
> *To:* Pat (Patricia) Thaler
> *Cc:* Pascal Thubert (pthubert); Toerless Eckert (eckert);
> [email-masked]; Dan Romascanu ([email-masked]); Glenn
> Parsons; Homenet; Alia Atlas; Acee Lindem (acee); Eric Gray; Mikael
> Abrahamsson
>
> *Subject:* Re: [ieee-ietf-coord] [homenet] Despair
>
>
>
> On Sat, Aug 8, 2015 at 9:07 AM, Pat (Patricia) Thaler <
> [email-masked]> wrote:
>

---

From: "Stephens, Adrian P" <[email-masked]>
Date: Mon, 10 Aug 2015 09:39:43 +0000

Hello Mikael,

Please see my responses embedded below...

Best Regards,
 
Adrian P STEPHENS

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: [email-masked]; Dan Romascanu ([email-masked]); Glenn Parsons; [email-masked]; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11

As far as I can tell, so far people have told IETF it's their job to reduce multicast to make IP based protocol "work" on 802.11 media. That's at least what I have been seeing. Considering the reactions from other parties, it seems the "multicast sucks on 802.11" is something 802.11 hasn't heard of before.

[Adrian P Stephens] 
This problem is nothing new.  We know about the relative performance of multicast vs unicast.
Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You are getting more than you are paying for :0).

The only thing IETF can do is to use less multicast, and the obvious way of solving it is to just replicate into unicast. This seems like a suboptimal way to work around the problem if there are a lot of nodes.

[Adrian P Stephens] 
The technical solution is surely to add a class of service specification to multicast packs that indicates their sensitivity to loss.
The point is that the AP is in possession of a lot of data about individual nodes that may help it make an informed decision
between unicast and multicast.

Moving the duplication into the IP layer ensures uninformed decisions.

>From what I read below, one way out of this is the IETF making a clear
statement that multicast is an integral part of IP networking, and if a medium doesn't support delivering multicast frames in a similarily reliable fashion to unicast, it's not suited to carrying IP based protocols (or any other protocol that uses L2 broadcast/multicast).

[Adrian P Stephens] 
<irony type="british; very-subtle">
I'm guessing you will be the first to turn off the 802.11 networking on your devices when the IETF makes such a statement.
</irony>

Write an RFC stating requirements on L1/L2 protocols when it comes to unicast, multicast and broadcast handling of packets. This could include options for mechanisms that turned multicast/broadcast into unicast that certain medias could have as requirements. Then IEEE could create a device profile that would fulfil these requirements, possibly add a certification, and then try to get market pressure to require devices to support this profile. The IETF wouldn't change its mind about how multicast is used in its protocols after this, but just say "this is the reality, please deal with it when you create L1/L2 that's supposed to carry IP".

Or the IETF could just say that this seems like a lost cause, multicast/broadcast doesn't seem to work on some L1/L2, and start working on techniques that minimizes broadcast/multicast and change all the protocols to reflect this new reality.

Something in the middle, but anyway changing the requirements on IETF protocols to avoid using multicast if it can, documenting where it makes sense and when it doesn't.

Right now what I am seeing is that there are people who are lobbying to do away with multicast as much as possible because they see that in reality it's not reliable on the devices they have tested it on.

What are the odds that 802.11 could agree on a device profile for "IP use" 
that would include reliable multicast delivery, and one that there is reasonable belief that this would gain significant market adoption?
[Adrian P Stephens] 
As I indicated in my earlier post,  there are multiple actors here.
The odds are pretty good that 802.11 will respond to a clear requirement to handle multicast specially.
If has,  after all,  already done this twice.

What are the odds that the WFA will create a new certification?
What are the odds that it is successful in the market?

These are presently unknowns,  and will remain that way until tried.

On Mon, 10 Aug 2015, Stephens, Adrian P wrote:

> Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
>
> Cc: Pascal Thubert (pthubert); Pat (Patricia) Thaler; 
> Parsons; Homenet; Eric Gray

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 10:05:54 +0000

Hello Mikael

> The only thing IETF can do is to use less multicast, and the obvious way of
> solving it is to just replicate into unicast. This seems like a suboptimal way
> to work around the problem if there are a lot of nodes.

Many products do that. But then people immediately think about sending unicast only to those who need the packet. Good idea isn't it? 

The basic APs will apply rules like 'oh, we do not expect a router on Wi-Fi so let's drop all RS towards wireless'. Hardcoded in the box.
Clearly, a behavior like this that is not backed by a standard, appears to be working, well, until it is no more, and at worse people may 'learn' that they cannot have routers over Wi-Fi. Damn.

More advanced and expensive devices will learn addresses from snooping various protocols and devising their own way of figuring which address (unicast, multicast) which STA is listening to. 
But a DAD may easily be missed and a state may not be created when it should have. A protocol may be misinterpreted, some bug, some new version of the protocol. A state may be kept for too long and may cause denial of service.

Because none of that is standard, different special sauces from different vendors will cause interoperation issues. Think about the impact of firewalls that we have suffered over the years, applied to the network operation down to the basic protocols.

Vendor-specific magic heuristics about how to play with snooped state that are deployed today will have unpredictable effects on new protocols in the future that expect standard behavior from deployed boxes. 

Add to that new host behaviors like rapid renewal of IP addresses for privacy reasons and you see that the good idea above was the recipe to first shoot oneself in the foot and then all the way up.

> medium doesn't support delivering multicast frames in a similarily reliable
> fashion to unicast, it's not suited to carrying IP based protocols (or any
> other protocol that uses L2 broadcast/multicast).

Such a thing is just untrue. IP works on any link, it has to. That's why we do IP over Foo. Now all we need is IP over Wi-Foo for radios such as .11.
As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it.

> profile that would fulfil these requirements, possibly add a certification, and
> then try to get market pressure to require devices to support this profile.
> The IETF wouldn't change its mind about how multicast is used in its
> protocols after this, but just say "this is the reality, please deal with it when
> you create L1/L2 that's supposed to carry IP".
> 

That is not my conception of IP. That would be Inter-Some-Net protocol now.

> multicast/broadcast doesn't seem to work on some L1/L2, and start
> working on techniques that minimizes broadcast/multicast and change all
> the protocols to reflect this new reality.

Not All protocols, just IP basic things like ND, and then use IP multicast routing even in a ML subnet.
For ND, it is already done for 802.15.4, RFC 6775, will need some additional stuff to make it generic Wi-Foo.

> sense and when it doesn't.

This also has already started with the efficient ND work at 6MAN and many drafts from design team members.

Cheers,

Pascal

> away with multicast as much as possible because they see that in reality it's
> not reliable on the devices they have tested it on.
> 
> > " For me, it seems these 802.11 broadcast/multicast ACK functions
> should be "mandatory" to implement if the device wants to support IPv4
> and IPv6 networks.
> >
> > How do we achieve this?"
> >
> > The second is certification.  This is the not-so-simple task of persuading a
> sufficient number of WiFi-Alliance members
> > that it is in their economic interest to support the feature that a
> certification program can be created.   Even, given a
> >> The question in my mind is whether this discussion thread is uncovering
> any new requirements for the 802.11 standard.
> >
> > For me, it seems these 802.11 broadcast/multicast ACK functions should
> be "mandatory" to implement if the device wants to support IPv4 and IPv6
> networks.
> >
> > How do we achieve this?
> >
> > --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 12:09:26 +0200 (CEST)

> Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You are getting more than you are paying for :0).

I don't see how it's relevant that the spectrum is free? Even if this was 
done in a licensed spectrum I would still get 10% packet loss because 
multicast isn't ACKed, right?

> Moving the duplication into the IP layer ensures uninformed decisions.

That's my opinion as well. Thanks for confirming it.

> I'm guessing you will be the first to turn off the 802.11 networking on your devices when the IETF makes such a statement.

Well, since it seems 802.11 has mechanisms to make multicast delivery 
decently reliable, it seems it would be suited if the implementation 
actually included that mechanism. If it's omitted by the implementor, it's 
not. Currently I have no idea if my home network includes GCR or not. I 
also don't know if GCR needs client support.

> If has,  after all,  already done this twice.

What do you mean "specially"? What I've been bringing up is not to treat 
it specially, it's to treat it so that it works similarily to unicast. 
>From my point of view, without the GCR or similar mechanism, multicast is 
treated specially, ie it's being treated worse than unicast.

> These are presently unknowns,  and will remain that way until tried.

I have no history on this kind of subject, someone who has been involved 
in 802.11 perhaps could make an educated guess and share an opinion on 
what might be the path that has the best odds to succeed?

http://eprints.networks.imdea.org/275/1/L.%20Eznarriaga-MsC%20Thesis-September%202011.pdf

Btw, could you confirm that GCR in 802.11aa is something that is needed in 
both AP and clients to work? It seems like it would need to be. How widely 
implemented is it in clients? Is this a hardware issue or driver issue? 
Does the operating system need to support it as well?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 12:15:58 +0200 (CEST)

> As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it.

Yes, but what about when multicast is there but it's less reliable 
compared to unicast? Is this also IPs problem?

Again, if if's IPs problem then if 802.11 would just clearly state that 
this is the case, then we have a way forward. I just hope 802.11 
understand that it'll see a lot more unicast coming its way and be 
prepared to handle it.

> This also has already started with the efficient ND work at 6MAN and many drafts from design team members.

Remember to get IETF chair to say this and give this as a clear 
directional statement how things should be done going forward, just the 
same way it's been said regarding security and encryption. I have little 
problem with this approach as long as we have consensus that this is the 
way things should be done.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 03:26:59 -0700

Pascal:

> Clearly, a behavior like this that is not backed by a standard, appears to be working, well, until it is no more, and at worse people may 'learn' that they cannot have routers over Wi-Fi. Damn.

Do we have a hall of shame somewhere for such behavior ? Would like to know
what AP to avoid ;-)

> But a DAD may easily be missed and a state may not be created when it should have. A protocol may be misinterpreted, some bug, some new version of the protocol. A state may be kept for too long and…

Right. That multicast to unicast conversion is all non-standard, and at it's
best most likely only working (well?) for actual media streaming, not signaling.

> As for protocols that rely on IP multicast, it's IP's problem. If the underlying link layer does not have multicast, it is IP's responsibility to emulate it.

Right... if it can. But its a bit a question what device-model we want to
expect. I fear that the worst possible device model is something like
a homenet router with an L3 interface that is bridged by a featureless L2
switch chip onto multiple wired ports, one of which is connecting to a
bad L2 WiFi-AP. On the othrer hand is the homenet AP where the IPv6 layer
can query per-client WiFi information from L2. So, which device model
do we want to build out a solution for ?

Btw: my answer: I wish we could move the industry to the latter, but i fear
for early adoption we need to support the first too.

Cheers
    Toerless

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 10:43:56 +0000

> >> statement that multicast is an integral part of IP networking, and if
> >> a medium doesn't support delivering multicast frames in a similarily
> > Such a thing is just untrue. IP works on any link, it has to. That's why we
> do IP over Foo. Now all we need is IP over Wi-Foo for radios such as .11.
> > As for protocols that rely on IP multicast, it's IP's problem. If the
> underlying link layer does not have multicast, it is IP's responsibility to
> emulate it.
> 
> Yes, but what about when multicast is there but it's less reliable compared
> to unicast? Is this also IPs problem?

Yes it is. IP over Foo must indicate if IP multicast over a link uses L2 mechanisms or not.

If not, a router learns from MLD the state it needs to figure to which devices it should copy a given packet.

For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea. 

Rather, a good idea could be to build a multilink subnet with APs that are also routers to serve the wireless edge, whereby the Ethernet backbone can rely on L2 broadcast while the wireless edge is routed. Many LLNs work like this. Why should Wi-Fi be an exception?

> 
> Again, if if's IPs problem then if 802.11 would just clearly state that this is
> the case, then we have a way forward. I just hope 802.11 understand that
> it'll see a lot more unicast coming its way and be prepared to handle it.
 
I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE to do an immensely scalable L2 multicast support so that Solicited Node Multicast appears so cool on a switched fabric? Does not seem to work either. 

The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo in general which would be my take. And then the IETF has to decide if it wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join the effort so we do the job right.

Cheers,

Pascal

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 13:03:08 +0200 (CEST)

> Yes it is. IP over Foo must indicate if IP multicast over a link uses L2 mechanisms or not.

Ok, so am I interpreting you correctly that there are three profiles for 
L1/L2 mediums:

1. Multicast works approximately the same way as unicast (packet loss)
2. Multicast works worse than unicast and should be minimized
3. Multicast not supported

So what we're missing is taking into account the #2 profile in the IETF, 
because so far we've only really understood that #1 and #3 exists?

> For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea.

But I keep hearing from the 802.11 experts (at least they seem to be) that 
there are 802.11 mechanisms that seem to make multicast work well enough 
and that there are power upsides to using multicast?

> Rather, a good idea could be to build a multilink subnet with APs that 
> are also routers to serve the wireless edge, whereby the Ethernet 
> backbone can rely on L2 broadcast while the wireless edge is routed. 
> Many LLNs work like this. Why should Wi-Fi be an exception?

Well, I am not wireless expert, I don't know if it makes more sense to 
treat each device to its own subnet and thus send RAs to each and every 
one of them as needed, or if it makes sense to have some kind of multicast 
mechanism and make sure that they all get this multicast packet in a 
shared subnet. Your suggestion seems perfectly fine for me from an IP 
point of view, actually I prefer that option as well. Basically each host 
has its own /64.

> I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE 
> to do an immensely scalable L2 multicast support so that Solicited Node 
> Multicast appears so cool on a switched fabric? Does not seem to work 
> either.
>
> The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo 
> in general which would be my take. And then the IETF has to decide if it 
> wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may 
> join the effort so we do the job right.

Are there more types of profiles we need? Does it make more sense to send 
a multicast packet if there are more (or less) than X nodes in a subnet, 
send unicast to each and every one of them if it's less (or more) than Y. 
Should each individual device be able to say what it prefers in case we're 
mixing battery powered devices and wired devices in the same place?

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 10 Aug 2015 11:31:29 +0000

To come back on the discussion why mcast matters for IPv6 while bcast does
not for IPv4:
- IPv6 uses heavily mcast while in IPv4 (ND is quite chatty)
- IPv6 uses many more addresses than IPv4 (hence even more chatty)

A couple of us running very large (more than 10000 STA) WiFi network have
experimented issues on dual-stack WiFi deployment cause by this chattiness
of IPv6 over mcast. (and not so much about the packet loss as far as I can
remember but more about wasting airtime to transmit 'tons of mcast'), and,
noticing as a side effect than battery life was impacted.

-éric

On 7/08/15 09:36, "homenet on behalf of Juliusz Chroboczek"
<[email-masked] on behalf of [email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2015 11:36:59 +0000

Unsure about your profile, Mikael. Ethernet would be a #2 by now, only things like sat-links could still be  #1s. So the work would really be to figure out what to do with the varieties of your #2. My question is rather whether IP over 802.11 should be operated like IP over Ethernet or like IP over 802.15.4.

Trouble is, some multicast ore more important than others. E.g. you miss an RA, usually no harm done, wait for the next or RS to force one. You missed a DAD, the protocol failed. If we start retrying DADs, we make the broadcast situation even worse. So to your point about energy, Wi-Foo may decide to broadcast some messages, unicast others multiple times, and at some point change the IP protocols so that the protocols operate differently. 

The IETF already made these steps for 802.15.4. RAs are still broadcasted but DAD was changed to be reliable and unicast-based.

The multilink subnet is not one /64 per wireless device as you indicate. That model certainly works too, and was deployed, but with it,  a set of 64 bits identifies and routes to a device, so we are mostly back to a world of IPv4 with just DHCP (PD) and identifiers of 64 bits instead of 32.

The multilink subnet is a single large subnet encompassing the whole ESS, Ethernet  + Wi-Fi. It is really a Layer-3 ESS, based on the same ideas as the Layer-2 is.

In that model, the association of a wireless device associates the IP unicast and multicast addresses with the MAC address, and the AP acts as a router and performs proxy ND over the Ethernet backbone on behalf of the wireless devices. That way, the ND NS are never multicast over the wireless. In practice, the association of IP addresses should be done as part of ND, and that is what RFC 6775 does.
 
Cheers,

Pascal

Cheers,

Pascal

> Sent: lundi 10 août 2015 13:03
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; Dan Romascanu ([email-masked])
> <[email-masked]>; Stephens, Adrian P
> <[email-masked]>; Glenn Parsons
> <[email-masked]>; [email-masked]; Homenet
> <[email-masked]>; Eric Gray <[email-masked]>
> Subject: RE: [ieee-ietf-coord] Multicast on 802.11
> 
> 1. Multicast works approximately the same way as unicast (packet loss) 2.
> Multicast works worse than unicast and should be minimized 3. Multicast
> not supported
> 
> there are 802.11 mechanisms that seem to make multicast work well
> enough and that there are power upsides to using multicast?
> 
> Well, I am not wireless expert, I don't know if it makes more sense to treat
> each device to its own subnet and thus send RAs to each and every one of
> them as needed, or if it makes sense to have some kind of multicast
> mechanism and make sure that they all get this multicast packet in a shared
> subnet. Your suggestion seems perfectly fine for me from an IP point of
> view, actually I prefer that option as well. Basically each host has its own
> /64.
> 
> > I'd hate this, IEEE telling IETF what to do. Just like IETF telling
> > IEEE to do an immensely scalable L2 multicast support so that
> > Solicited Node Multicast appears so cool on a switched fabric? Does
> > not seem to work either.
> >
> > The IETF has to decide if it wants to design IP over 802.11 - or
> > Wi-Foo in general which would be my take. And then the IETF has to
> > decide if it wants to design IP over a mix of Wi-Fi and Ethernet. IEEE
> > people may join the effort so we do the job right.
> 
> a multicast packet if there are more (or less) than X nodes in a subnet, send
> unicast to each and every one of them if it's less (or more) than Y.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Aug 2015 13:54:26 +0200 (CEST)

On Mon, 10 Aug 2015, Pascal Thubert (pthubert) wrote:

> Unsure about your profile, Mikael. Ethernet would be a #2 by now, only 
> things like sat-links could still be #1s. So the work would really be to

I don't agree, wired ethernet is still #1 if you ask me.

> figure out what to do with the varieties of your #2. My question is 
> rather whether IP over 802.11 should be operated like IP over Ethernet 
> or like IP over 802.15.4.

That is a good question.

> The multilink subnet is not one /64 per wireless device as you indicate. 
> That model certainly works too, and was deployed, but with it, a set of 
> 64 bits identifies and routes to a device, so we are mostly back to a 
> world of IPv4 with just DHCP (PD) and identifiers of 64 bits instead of 
> 32.
>
> The multilink subnet is a single large subnet encompassing the whole 
> ESS, Ethernet + Wi-Fi. It is really a Layer-3 ESS, based on the same 
> ideas as the Layer-2 is.
>
> In that model, the association of a wireless device associates the IP 
> unicast and multicast addresses with the MAC address, and the AP acts as 
> a router and performs proxy ND over the Ethernet backbone on behalf of 
> the wireless devices. That way, the ND NS are never multicast over the 
> wireless. In practice, the association of IP addresses should be done as 
> part of ND, and that is what RFC 6775 does.

Ok, thanks for explaining what you meant in more detail. I think I got it 
now.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 10 Aug 2015 14:08:52 +0100

Folks, please trim your cc: lists - you're exceeding the limit that
Mailman permits and I don't intend to increase it (nor pass through any
messages already blocked as a result).

thanks,

Ray

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Aug 2015 16:01:17 +0200

> cheaper. An RA will likely only be 100 or 200 bytes.

First 802.11 has aggregation, so it is possible to combine the unicast
media access with other outgoing unicasts.

There is also multi-user MIMO coming, which means a AP can talk to
several other stations simultaneously.

Both factors can make multiple short unicast frames more efficient
than a single multicast, but only the linklayer has enough information
to decide this.

Henning Rogge

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Aug 2015 10:16:04 -0700

> On Aug 6, 2015, at 17:42, Juliusz Chroboczek <[email-masked]> wrote:
> 

An additional complication with 802.11 is that various physical encodings use spacial beam forming for unicast and that’s not possible with multicast. It’s the main reason that transmission bit rates for unicast can be so much higher than for multicast— perhaps surprisingly so for people only accustomed to wired physical networking scenarios. It also has murky effects on coexistence between overlapping service sets, which are extremely common in high-density residential environments.

—james

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 10 Aug 2015 19:36:40 +0200

> The default is 600s, not 60s.

Ouch.

(And thanks for the correction.)

-- Juliusz

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 10 Aug 2015 10:46:15 -0700

On Mon, Aug 10, 2015 at 10:16:04AM -0700, james woodyatt wrote:
> An additional complication with 802.11 is that various physical encodings use spacial beam forming for unicast and that???s not possible with multicast. It???s the main reason that transmission bit rates for unicast can be so much higher than for multicast??? perhaps surprisingly so for people only accustomed to wired physical networking scenarios. It also has murky effects on coexistence between overlapping service sets, which are extremely common in high-density residential environments.

Sure, but you could probably equally well use beamforming and mimo to improve
efficiency of multicasted packets. Aka: send a single beamformed packet to
N > 1 stations in roughly the same direction.

Without MiMo/Beamforming, i think multicasting a packet is airtime beneficial
when it replaces N > 1 unicast. With MiMo/Beamforming it's maybe N > 4..10 or
the like. 

Cheers
    Toerless

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 10 Aug 2015 20:05:11 +0200

> Such a thing is just untrue. IP works on any link, it has to. That's why
> we do IP over Foo.

Agreed, IP is supposed to work on anything from 10Gb/s fiber to carrier
pigeons.  The market has chosen, IP has eaten all of the protocols that
required special support from the link layer.  If a link layer doesn't
fit, we design an adaptation shim (I'm looking at you, ARCNET).

However, this doesn't prevent us from giving advice to link layer
designers for best IP performance.  RFC 3819 (BCP 89) has the following to
say:

   Subnetworks using shared channels (e.g., radio LANs, Ethernets) are
   especially suitable for native multicasting, and their designers
   should make every effort to support it.

Since RFC 3819 is mostly concerned about avoiding receiving unwanted
multicast, it doesn't say anything about the performance of multicast
itself.  Is an update needed?

-- Juliusz

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Mon, 10 Aug 2015 18:41:42 +0000

There are potentially ways of addressing higher loss rates for multicast that should be explored before going to replicated unicast.

>...  I have yet to hear about anyone using 802.11 for 
> percent packet loss doesn't count as "work" in a packet data network,) and
> moved to wires instead. ...

There are different use cases with different requirements on the underlying network. The needs and constraints of video streaming are different than those of protocols such as ND (neighbor discovery). The solutions that work for one may not apply to the other. 

> If you miss a couple of consecutive RAs in IPv6, you abandon your prefix 
which wouldn't apply at all to video streaming. On the other hand, potentially work done in DetNet could help with video streaming but might not be a good fit for the use of multicast to maintain IPv6.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 10 Aug 2015 14:48:49 -0400

Hi Adrian,

I am encouraging those interested to wrote a draft indicating the observed
issues and perhaps exploring the solution space.   I assume that's what you
would need to start having a meaningful discussion on reasonable options.

Thanks,
Alia
On Aug 10, 2015 5:41 AM, "Stephens, Adrian P" <[email-masked]>
wrote:

> Cc: [email-masked]; Dan Romascanu ([email-masked]); Glenn
> Parsons; [email-masked]; Homenet; Eric Gray
> Saying it "sucks" is not very helpful.   Unlicensed spectrum is free.  You
> are getting more than you are paying for :0).
>
>
> The technical solution is surely to add a class of service specification
> to multicast packs that indicates their sensitivity to loss.
> The point is that the AP is in possession of a lot of data about
> individual nodes that may help it make an informed decision
> I'm guessing you will be the first to turn off the 802.11 networking on
> your devices when the IETF makes such a statement.
> </irony>
>
>
>
> profile that would fulfil these requirements, possibly add a certification,
> and then try to get market pressure to require devices to support this
> profile. The IETF wouldn't change its mind about how multicast is used in
> its protocols after this, but just say "this is the reality, please deal
> with it when you create L1/L2 that's supposed to carry IP".
>
> > " For me, it seems these 802.11 broadcast/multicast ACK functions should
> > The second is certification.  This is the not-so-simple task of
> persuading a sufficient number of WiFi-Alliance members

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Aug 2015 19:58:16 -0500

On Aug 10, 2015, at 1:05 PM, Juliusz Chroboczek <[email-masked]> wrote:

> multicast,

I don't know why you would get that impression. I helped write that section (as noted in sec 19). Native L2 multicast should be supported exactly because it's useful to IP, as noted here:

---
Multicasting is considerably more efficient when a subnetwork explicitly supports it.
---

Joe

> it doesn't say anything about the performance of multicast

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:08:27 -0700

> If not, a router learns from MLD the state it needs to figure to which devices it should copy a given packet.

Well, the problem with WiFI is that L2 multicast  are useful under some
conditions and not useful under others. And the conditions are more
complex than boolean ;-)

> For Wi-Fi, there is no multicast support and it is sufficiently clear now that relying on broadcast is not a good idea. 

Pretty sure you don't mean that. If you would eliminate ALL multicast, you
didn't have discovery of new devices.

> Rather, a good idea could be to build a multilink subnet with APs that are also routers to serve the wireless edge, whereby the Ethernet backbone can rely on L2 broadcast while the wireless edge is…

Thats why i asked what device model we need. Don't think i got an
answer for that though. L3 homenet APs would be lovely. But will it
be sufficient to ONLY support those theoretical devices in homenet ?

> I'd hate this, IEEE telling IETF what to do. Just like IETF telling IEEE to do an immensely scalable L2 multicast support so that Solicited Node Multicast appears so cool on a switched fabric? Does…

Sure.

> The IETF has to decide if it wants to design IP over 802.11 - or Wi-Foo in general which would be my take. And then the IETF has to decide if it wants to design IP over a mix of Wi-Fi and Ethernet.…

Getting IPv6 link signaling work with WiFi sucking L2 multicast
is just a bit of work in the L2 IPv6 protocols that can be done
IMHO without botrhering IEEE. Getting streaming multicast work 
best requires more L2 awareness and it doesn't seem homenet
is interested in thast anyhow, so i think we're only going to get
a solution for the L2 IPv6 signaling piece realistically in the
IETF alone.

Cheers
    toerless

---

From: Alia Atlas <[email-masked]>
Date: Tue, 11 Aug 2015 12:15:49 -0400

Can we please remove [email-masked] from this conversation?
Once we as the IETF figure out what to write down and discuss, that'll be a
good time to interact,
but I think this conversation is really not the point of that list.

It's already cc'd to mboned and homenet...

Thanks,
Alia

On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert <[email-masked]> wrote:

> > For Wi-Fi, there is no multicast support and it is sufficiently clear
> now that relying on broadcast is not a good idea.
>
> are also routers to serve the wireless edge, whereby the Ethernet backbone
> can rely on L2 broadcast while the wireless edge is routed. Many LLNs work
> like this. Why should Wi-Fi be an exception?
>
> wants to design IP over a mix of Wi-Fi and Ethernet. IEEE people may join
> the effort so we do the job right.
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:28:54 -0700

> The only thing IETF can do is to use less multicast, and the obvious way of solving it is to just replicate into unicast. This seems like a suboptimal way to work around the problem if there are a…

When replacing multicast with unicast its not necessary to replicate,
you can instead use different protocol mechanisms too, eg: client/server
communications. Especailly wrt to the p2p duplicate address detection.

> between unicast and multicast.

For the signaling that IPv6 needs it looks like a lot of waste of
complex L2 tracking (like those protected GCR's) to create reliability.

> Moving the duplication into the IP layer ensures uninformed decisions.

Yes, but only about optimizations unnecessary for signaling. Which is
why i said we should be more specific about what use of multicast
we're talking about: signaling or media. They need different
solution approaches IMHO.

> Write an RFC stating requirements on L1/L2 protocols when it comes to unicast, multicast and broadcast handling of packets. This could include options for mechanisms that turned multicast/broadcast…

Yeah, that doesn't work.

> Or the IETF could just say that this seems like a lost cause, multicast/broadcast doesn't seem to work on some L1/L2, and start working on techniques that minimizes broadcast/multicast and change a…

Yes, for IPv6 L2 signaling.

> Something in the middle, but anyway changing the requirements on IETF protocols to avoid using multicast if it can, documenting where it makes sense and when it doesn't.

That too.

Cheers
    Toerless

> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 11 Aug 2015 09:30:50 -0700

Sure... 
But don't look at me, i don't remember i added that Cc:, i added mboned ;-))

---

From: Alia Atlas <[email-masked]>
Date: Tue, 11 Aug 2015 14:08:32 -0400

https://tools.ietf.org/html/draft-vyncke-6man-mcast-not-efficient-01 may be
of interest in understanding some of the issues with IPv6 and wifi.

Regards,
Alia

On Tue, Aug 11, 2015 at 12:30 PM, Toerless Eckert <[email-masked]> wrote:

> > > > Yes it is. IP over Foo must indicate if IP multicast over a link
> uses L2
> > > mechanisms or not.
> > > >
> > > > If not, a router learns from MLD the state it needs to figure to
> which
> > > devices it should copy a given packet.
> > >
> backbone
> > > > > it'll see a lot more unicast coming its way and be prepared to
> handle
> > > it.
> > > >
> IEEE
> Wi-Foo

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 11 Aug 2015 19:34:18 +0200

I'm removing from CC the people who I know are on Homenet, please do the
same with the other lists.

> I don't know why you would get that impression. I helped write that
> section (as noted in sec 19). Native L2 multicast should be supported
> exactly because it's useful to IP, as noted here:
> 
> ---

Perhaps I misread this section, but the impression I get is that it is
concerned about avoiding waking nodes and avoiding duplicate
transmissions.  I doesn't read like the authors are thinking about
networks where multicast has higher packet loss and lower throughput than
unicast, which is what concerns us here.

I'd love to be proved wrong.

-- Juliusz

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 13:59:15 -0700

On 8/11/2015 10:34 AM, Juliusz Chroboczek wrote:
> Perhaps I misread this section, 

Are you referring to RFC3819?

> but the impression I get is that it is
> transmissions.

This is incorrect. The section is basically saying "IP works better when
L2 supports multicast so L3 (IP) doesn't have to emulate it".

The assumption is that L2 will do a reasonably good and efficient job of
multicast/broadcast - certainly better than L3 or other layers would.

> I doesn't read like the authors are thinking about

The point of that section is that IP is more complex when it has to
emulate something that L2 doesn't provide. If it's more efficient to
implement L2 multicast via serial copy than by shared channels, that's
L2's decision.

The point of the RFC is to NOT make this the job of L3. L3 is a bad
place to support multicast or broadcast on subnets.

Joe

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 21:44:24 +0000

RE: RFC3819

> multicast/broadcast - certainly better than L3 or other layers would.

What I think Juliuz is trying to point out is that the RFC doesn't talk about how good the performance of L2 multicast needs to be - for instance in terms of BER/packet loss. It does talk about the impact of BER on TCP throughput, but not on multicast. 

How good an error rate do the IPv6 related multicasts need?

Adrian summarized the causes of packet loss:
"1.  The basic "packet error rate" (before Ack) designed to is 10% in the case of unicast.   This is a very broad statement and almost so
simplistic as to be misleading.    Errors are composed of 1) collisions, 2) interference,  3) rate/MCS adaptation
errors,  4) sudden changes in the radio environment such as shadowing.   The residual error for unicast is less because of the retry mechanism.

...." 

If it takes two missed RAs to decide that you aren't connected to the router any more, that has about a 1% chance of happening with a 10% packet error rate (though the multicast error rate is probably somewhat better since it is sent at the lower rate). This assumes that the error probability for the two RAs is independent; they occur far enough apart in time that this doesn't seem unreasonable. 
 
Why does it take two lost RAs rather than one? Presumably because the protocol assumes that sometimes an RA is lost, just not with as high a probability as 10%.

1% seems high - how good does it need to be for acceptable behavior? One could improve the behavior by adjusting parameters so that more than 2 had to be lost. Of course there is a tension between bandwidth for multicast heartbeats, wanting to detect reasonably quickly that the device is no longer on the subnet (e.g. because it is mobile), and not losing the context unnecessarily.

Without guidance on how good the multicast packet loss rate should be, it is difficult to define the best solution .

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 21:46:43 +0000

I think it is useful for [email-masked]<mailto:[email-masked]> to be in the conversation. Some of the participants in the discussion are on that reflector and I don’t know that they are on homenet or mboned.

Pat

From: ieee-ietf-coord [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Tuesday, August 11, 2015 9:16 AM
To: Toerless Eckert
Cc: [email-masked]; Homenet; [email-masked]
Subject: Re: [ieee-ietf-coord] [homenet] Multicast on 802.11

Can we please remove [email-masked]<mailto:[email-masked]> from this conversation?
Once we as the IETF figure out what to write down and discuss, that'll be a good time to interact,
but I think this conversation is really not the point of that list.

Thanks,
Alia

On Tue, Aug 11, 2015 at 12:08 PM, Toerless Eckert <[email-masked]<mailto:[email-masked]>> wrote:

Sure.

Cheers
    toerless

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Aug 2015 14:54:01 -0700

On 8/11/2015 2:44 PM, Pat (Patricia) Thaler wrote:
> What I think Juliuz is trying to point out is that the RFC doesn't
> talk about how good the performance of L2 multicast needs to be -
> for instance in terms of BER/packet loss. It does talk about the
> impact of BER on TCP throughput, but not on multicast.

Agreed.

> How good an error rate do the IPv6 related multicasts need?

I would expect that depends on the use, e.g., DAD would be different
than streaming multimedia.

> If it takes two missed RAs to decide that you aren't connected to
> the router any more, that has about a 1% chance of happening with a 10%
> packet error rate (though the multicast error rate is probably
> somewhat better since it is sent at the lower rate). This assumes that
> the error probability for the two RAs is independent; they occur far
> enough apart in time that this doesn't seem unreasonable.
> 
> Why does it take two lost RAs rather than one? Presumably because
> the protocol assumes that sometimes an RA is lost, just not with as
> high a probability as 10%.
> 
> 1% seems high - how good does it need to be for acceptable behavior? 
> One could improve the behavior by adjusting parameters so that more
> than2 had to be lost. Of course there is a tension between bandwidth
> formulticast heartbeats, wanting to detect reasonably quickly that
> thedevice is no longer on the subnet (e.g. because it is mobile), and
> notlosing the context unnecessarily.
> 
> Without guidance on how good the multicast packet loss rate should
> be, it is difficult to define the best solution .

While I agree with your conclusion, what's the alternative if there is
no L2 multicast?

I think you're arguing for more specific guidance on acceptable packet
loss rates for various uses of multicast, but that might be out of scope
for RFC3819 (even as a -bis). I gave it a quick scan, and as I checked
(and recall) RFC3819 doesn't make specific recommendations on BER for
unicast either. It says that the BER needed depends on the use, and that
can affect the efficiency of L3. The same is true for multicast, but
that doc is not the place for a specific recommendation.

Joe

---

From: "Pat (Patricia) Thaler" <[email-masked]>
Date: Tue, 11 Aug 2015 22:32:35 +0000

Joe, 

I'm mainly concerned in this discussion on what error rate is needed for acceptable performance of the protocols that support IPv6 - e.g. DAD, RA. Streaming multimedia is a separate discussion since different solutions might apply to it. 

> While I agree with your conclusion, what's the alternative if there is

802.11 does have L2 multicast. It just doesn't provide for L2 ack and retry for L2 multicast (at least in its basic form, there is a recent optional extension for that) so the packet loss can be higher than that for unicast.

> that doc is not the place for a specific recommendation.

I don't think advice on that would be out of place as "Advice for Internet Subnetwork Designers" if it is what is needed to make IPv6 work well. People here have expressed consternation that 802.11 doesn't have good enough performance for that, but how can you expect subnets to provide that performance  when the need hasn't been included in the advice.

Even if the number doesn't get put into an RFC3819-bis, it would be useful to have a number so that solutions can be examined.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 07:17:47 +0200 (CEST)

On Tue, 11 Aug 2015, Pat (Patricia) Thaler wrote:

> Without guidance on how good the multicast packet loss rate should be, 
> it is difficult to define the best solution .

I'd say most applications people actually use start behaving very badly 
around 0.1 - 1% packet loss. VoIP MOS goes down, TCP starts to really get 
affected etc. I'd imagine most people I interact with that design 
protocols design protocols have in their mind that the packet loss rate is 
around this level, not higher.

So for me, the "contract" that 802.11 needs to fulfil for the IETF not to 
start looking into changing IP for 802.11, is for 802.11 networks to 
deliver broadcast and multicast packets with around 0.1% packet loss (or 
less) as a design goal for normal operations.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 12 Aug 2015 07:51:46 +0200

On Wed, Aug 12, 2015 at 7:17 AM, Mikael Abrahamsson <[email-masked]> wrote:
> affected etc. I'd imagine most people I interact with that design protocols
> design protocols have in their mind that the packet loss rate is around this
> level, not higher.
>
> start looking into changing IP for 802.11, is for 802.11 networks to deliver
> broadcast and multicast packets with around 0.1% packet loss (or less) as a
> design goal for normal operations.

The problem is we are dealing with more and more wireless devices, so
the medium starts to become congested more easily.

0.1% - 1% packet loss (not frame loss) is possible for unicast, but
0.1% multicast packet loss is unrealistic.

Henning Rogge

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Wed, 12 Aug 2015 06:50:05 +0000

What you mention is for media streaming, and the wifi problem is primarily burst loss. Correcting that is expensive, whether its done at l2 or higher layer. Our signaling protocols can easily be fixed to live with even higher loss at lower cost. Thats why i am suggesting to separate solution space between signalling and media.

Mikael Abrahamsson <[email-masked]> wrote:

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 12 Aug 2015 07:31:27 +0000

>0.1% multicast packet loss is unrealistic.

Some empirical measurements done on large WLAN are worse than those
numbers: range of 10% to 20% of mcast packets lost...

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 12 Aug 2015 10:12:05 +0200 (CEST)

> 0.1% multicast packet loss is unrealistic.

I found this interesting document:

https://hal.archives-ouvertes.fr/tel-00919403/document

In 2.4 there is a lot of text about different ways of making multicast 
(more) reliable.

>From what I can see, the control plane (for instance RA/ND/ARP etc) (this 
does not include video transmission) of IP based protocols have the 
following requirements for its broadcast/multicast packets (from now on I 
will only say multicast):

Multicast packets should be delivered with less than 1% packet loss 
Multicast packets should be delivered within 200-500ms (for instance DAD 
requires answer within 1s)

This would indicate to me that 802.11 could do the following to achieve a 
compromise between power, packet loss etc:

If the multicast packet is to be sent to X receivers or fewer, turn them 
into L2 unicast, and send them individually (tradeoff between sending X 
packets and using a lower rate multicast). X could be 2-4 or something?

Send IP control plane multicast packets at an interval, for instance 
250ms, so stations can sleep in between.

Send multiple packets at the above interval if there are multiple ones 
queued up, use BNAK for retransmits, potentially turning 
to-be-retransmitted multicast packets into unicast (re)transmits to send 
to individual stations that didn't receive the multicasted packet(s).

(I don't know if this is already being done) Stations should send IP 
multicast packets to the AP in L2 unicast so the AP can then send it as 
multicast using above mechanism, including queuing it for multiple 
delivery.

Thoughts?

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 11:23:29 -0700

On 8/11/2015 3:32 PM, Pat (Patricia) Thaler wrote:
> Joe, 
> 
> I'm mainly concerned in this discussion on what error rate is needed
> for acceptable performance of the protocols that support IPv6 - e.g.
> DAD, RA. Streaming multimedia is a separate discussion since different
> solutions might apply to it. 

Sure.

> 802.11 does have L2 multicast. It just doesn't provide for L2 ack 
> and retry for L2 multicast (at least in its basic form, there is a
> recent optional extension for that) so the packet loss can be higher
> than that for unicast.

Understood, but again, what's the alternative?

> I don't think advice on that would be out of place as "Advice for
> Internet Subnetwork Designers" if it is what is needed to make IPv6 work
> well. People here have expressed consternation that 802.11 doesn't have
> good enough performance for that, but how can you expect subnets to
> provide that performance when the need hasn't been included in the advice.

That's true, but specific protocol behaviors do address this issue
already, e.g., RFC 7559 uses exponential backoffs for soliciting RAs.

DAD is a "negative information" protocol, i.e., a lossy link can give a
false positive. This issue is already addressed Sec 4.4 of RFC 4429: the
effect of L2 losses can be mitigated by recommending a different value
for DupAddrDetectTransmits. RFC 4862 Sec 5.1 already notes that this
parameter might need to be defaulted to a different value for particular
link types, and such might need to be the case for 802.11.

> Even if the number doesn't get put into an RFC3819-bis, it would be
> useful to have a number so that solutions can be examined.

For this protocol mechanism, the numbers are a relationship:

	L2 mcast loss rate vs. DupAddrDetectTransmits value

IMO, it'd be a lot easier to increase DupAddrDetectTransmits than to
assume 802.11 would lower the L2 mcast loss rate.

Joe

---

From: Henning Rogge <[email-masked]>
Date: Wed, 12 Aug 2015 21:39:21 +0200

> link types, and such might need to be the case for 802.11.

Luckily DAD is mostly needed for randomized IPv6 addresses... if you
use the MAC address for generating the IP you are either fine or you
have a MAC level collision, which means you have an unsolvable
problem.

(it gets even worse on 802.11 IBSS/Adhoc mode)

Henning Rogge

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 13:08:34 -0700

> requires answer within 1s)

That assumes default DAD configuration, and I already noted that this is
clearly not appropriate for existing 802.11 links based on the recently
reported loss rates.

I.e., DAD doesn't have specific requirements; it has a *relationship* of
its configuration to the link properties.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Aug 2015 13:13:15 -0700

> have a MAC level collision, which means you have an unsolvable

DAD is also needed to detect duplicates due to host misconfiguration,
such as when a cloned MAC is added to the same network or when addresses
are duplicated by other means (e.g., DHCPv6 misconfiguration).

I couldn't confirm, but isn't this also not a local decision? I.e., if
DAD fails you might end up with a duplicate address even when you set
your IP addresses based on the burned-in MAC because others could select
the same address randomly (I didn't see how that was avoided by the
self-assignment algorithm).

Joe

---

From: Henning Rogge <[email-masked]>
Date: Thu, 13 Aug 2015 06:35:50 +0200

> self-assignment algorithm).

If you have a duplicate MAC then DAD will not safe you... you cannot
communicate anyways because of a layer-2 problem.

Henning Rogge

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Aug 2015 07:25:51 +0200 (CEST)

> communicate anyways because of a layer-2 problem.

Well, you can share the same L3 network but not share the same L2 network 
(and do proxy-ND between them). But yes, you're basically correct.

---

From: james woodyatt <[email-masked]>
Date: Thu, 13 Aug 2015 10:59:20 -0700

> communicate anyways because of a layer-2 problem.

Yes, and DAD also has logic that limits the damage on the entire network when hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862.

>    If the address is a link-local address formed from an interface
>    identifier based on the hardware address, which is supposed to be
>    uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
>    operation on the interface SHOULD be disabled.

It’s worth noting that the presence of network sleep proxies can make this recommendation problematic. It would be better to disable the whole interface only when the actual L2 address is discovered to be duplicated, not just the link-local IPv6 address w/ embedded EUI-64 IID, which would allow DAD failures with sleep proxies on link-local addresses to be treated like a DAD failure with a sleep proxy on any other address. Alas, earwax.

—james

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Aug 2015 11:13:05 -0700

On 8/13/2015 10:59 AM, james woodyatt wrote:
> On Aug 12, 2015, at 21:35, Henning Rogge <[email-masked]
> <mailto:[email-masked]>> wrote:
...
> Yes, and DAD also has logic that limits the damage on the entire network
> when hosts join with duplicate L2 addresses, c.f. section 5.4.5 of RFC 4862.

Also, a duplicate L2 is a problem at L2 only when both L2s are on the
same L2 subnet. It's entirely possible that the two L2s are on different
L2 subnets but on the same L3 subnet.

E.g., consider point-to-point links to the router. No reason to care
about the L2s at all (interface is all you need to determine the remote
end), but nodes that self-address using identical L2s would create
identical L3's.

Joe

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Aug 2015 16:17:15 +0000

Hello Alia:

The solution space has been explored in the context of WPANs (802.15.4, BTLE…) and there is certainly value in extending this to WLANs. We have running code that was tested between vendors (twice already) at 6TiSCH plug fests and is scheduled for official plugtest in Berlin next year.

The solution splits the broadcast domain by making the hybrid wired/wireless network a MultiLink Subnet. ND operations on the wireless links derives from RFC 6775 and the use of multicast for ND is dramatically reduced. Backbone routers perform proxy ND operations to integrate with the wired backbone. The overall design is pretty much an echo at layer-3 of the association process that was designed for 802.11 and that is much more suitable to wireless than IPv6 ND’s multicast-based operations.

I just updated the (years old, used to be a 6LowPAN WG doc from which RFC 6775 actually derives) backbone router draft. The problems is summarized by referencing other drafts from Andrew, Eric, Erik, Samita, and others, and I detailed the protocol operations as my memory and a crude code lookup tells me it is implemented. It is broadly correct but there are devils in the details and we’ll need to refine as usual.

URL:            https://www.ietf.org/internet-drafts/draft-thubert-6lo-backbone-router-00.txt

Htmlized:       https://tools.ietf.org/html/draft-thubert-6lo-backbone-router-00

Take care,

Pascal

From: homenet [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: lundi 10 août 2015 20:49
To: Adrian P Stephens <[email-masked]>
Cc: [email-masked]; Dan Romascanu ([email-masked]) <[email-masked]>; Glenn Parsons <[email-masked]>; [email-masked]; Homenet <[email-masked]>; Mikael Abrahamsson <[email-masked]>; Eric Gray <[email-masked]>
Subject: Re: [homenet] [ieee-ietf-coord] Multicast on 802.11

Hi Adrian,

I am encouraging those interested to wrote a draft indicating the observed issues and perhaps exploring the solution space.   I assume that's what you would need to start having a meaningful discussion on reasonable options.

Thanks,
Alia
On Aug 10, 2015 5:41 AM, "Stephens, Adrian P" <[email-masked]<mailto:[email-masked]>> wrote:
Hello Mikael,

Best Regards,

Adrian P STEPHENS

Tel: +44 (1793) 404825<tel:%2B44%20%281793%29%20404825> (office)
Tel: +1 (971) 330 6025<tel:%2B1%20%28971%29%20330%206025> (mobile)

-----Original Message-----
From: ieee-ietf-coord [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mikael Abrahamsson
Sent: 10 August 2015 10:27
To: Stephens, Adrian P
Cc: [email-masked]<mailto:[email-masked]>; Dan Romascanu ([email-masked]<mailto:[email-masked]>); Glenn Parsons; [email-masked]<mailto:[email-masked]>; Homenet; Eric Gray
Subject: [ieee-ietf-coord] Multicast on 802.11

(included [email-masked]<mailto:[email-masked]> and also changed subject to something more
appropriate)

[Adrian P Stephens]

[Adrian P Stephens]

[Adrian P Stephens]

On Mon, 10 Aug 2015, Stephens, Adrian P wrote:

> From: ieee-ietf-coord [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Mikael Abrahamsson
> [email-masked]<mailto:[email-masked]>; Dan Romascanu ([email-masked]<mailto:[email-masked]>); Glenn
> [email-masked]<mailto:[email-masked]>

_______________________________________________
ieee-ietf-coord mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ieee-ietf-coord