Re: [Mcast-wifi] Multicast and Wireless (fwd)

"Mark Hamilton" <> Wed, 19 July 2017 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CC4B13167D for <>; Wed, 19 Jul 2017 10:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.738
X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XWg5AQ2Ph5rN for <>; Wed, 19 Jul 2017 10:41:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB09512EBF4 for <>; Wed, 19 Jul 2017 10:41:24 -0700 (PDT)
Received: by with SMTP id l7so415983iof.5 for <>; Wed, 19 Jul 2017 10:41:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=4XCWNq+IJ6Ho5bYC7qOw/bFYcj+wJ9Hj0zpC8ZcDgig=; b=tZBmYtfT35aHdUrht0Aq5/joqVS81m3TJsZz3AucYtHHsU0AtlfsrggSW+K0BjYm7z NyMpyYtgGjee0GgbikwdYFU6R7uXN8HcfoN1dcZgqgEjcmk5ssF5Twrnr4ssn9G66/+O oDaORPdhqMmlFPnnlmIh/OhX2FxdcvDvtjGvJhqeYveeaplTLXPr6zv1GeWGlHtRXwAs f8N9ijEGyuDZuoC7sor6YutegMptUkhbf4Byq/l98G6WRguRHI98qrsLy6XoZ9c+gnir oC+QfsRhpH8iC4gQ9a4tG95yju9edtay4utYeGD2r/KdUcEe/uqsRzkskTTKgs+d25ug OlTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=4XCWNq+IJ6Ho5bYC7qOw/bFYcj+wJ9Hj0zpC8ZcDgig=; b=g3I6b5DYZfiz658KBD5buvmRxs7R1Pwx3La4acEj5AOrtiJXskpwx/e2BPqHYBkgK7 CjK1vrKG7jV3AiniWSKlvBvMT5fXqLDfx8WHPSSIfItl/R3VZW9kl5ue+yqDqiIanvRU fLBxChH4EXtRkLgXXVjS4KQC6RJpQeADxIZ7cOza8TZvQ5OwVzAm1SVR4vG1JFyot4/E TV8FgrWta07qKoAab0SmqmRAKpIzWVLPQV6l7VebdT5V/uU4o8bhb3e6GAsb9XLoC54x ArPg4dsh+3DFgKMhUHERWFJ3OHFhpLBzDw0oxsxOW5a5F3SoWjWLfSYpxmPK/REcZGd5 KFog==
X-Gm-Message-State: AIVw110+3Y+QMEzLjljVt5gfCNQtsItio3OxVRBe/RKv9pYp4OCxP1lp m6BuB87QEKkfhg==
X-Received: by with SMTP id g9mr1039366ioe.46.1500486084200; Wed, 19 Jul 2017 10:41:24 -0700 (PDT)
Received: from MarkPC ([]) by with ESMTPSA id o17sm282290ioe.1.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jul 2017 10:41:23 -0700 (PDT)
From: "Mark Hamilton" <>
To: "'Mikael Abrahamsson'" <>, <>
Cc: "'Donald Eastlake'" <>
References: <>
In-Reply-To: <>
Date: Wed, 19 Jul 2017 11:41:17 -0600
Message-ID: <00ef01d300b6$3b9dc6c0$b2d95440$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01D30083.F106B220"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJVV+Ij3AEer2MTFLPMSOS5lRe/qqFWtMKw
Content-Language: en-us
Archived-At: <>
Subject: Re: [Mcast-wifi] Multicast and Wireless (fwd)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions related to issues with multicast in 802.11 Wi-Fi networks & solutions/optimizations targeted at resolving these issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jul 2017 17:41:26 -0000

Thanks for the update, and prod, Mikael.  One clarification, and one


802.1ak has been pulled into 802.1Q as of 802.1Q-2011.  So just for clarity,
I think we're talking about 802.1Q-2014 [ ] (I assume we should
reference the latest), and its specification of MRP (clause 10, and


The question/remark: I apologize that I'm not up-to-speed on the discussions
during this gathering.  But, I am concerned with a consideration that 802.11
could somehow use MRP to help with this.  Typically, 802.11 is limited in
scope to being a "MAC/PHY stack" under (within?) a Bridge Port, and it is
does not understand or directly interact with any of the Bridging protocols
flowing over its links.  There is a project underway in 802.11 (802.11ak)
which will catch up 802.11 to the latest 802.1 specs for such links
(802.1AC, etc.), but I don't believe that will add sufficient understanding
of Bridging protocols to provide direct information from MRP, either.  Is
the suggestion that 802.11 be further enhanced to be able to participate in
MRP?  Or, is there confusion about 802.11 acting like a Bridge (and an
assumption that it would therefore participate in MRP, etc.), which is a
common issue?




-----Original Message-----
From: Mcast-wifi [] On Behalf Of Mikael
Sent: Wednesday, July 19, 2017 10:51 AM
Subject: Re: [Mcast-wifi] Multicast and Wireless (fwd)





Below is an email I wrote to the approximately 10 people who were "gathered"
to discuss how to proceed with the wifi-multicast "problem".


In the meeting, there were lots of discussions, some regarding catching up
with what had been discussed before, but the last 30 minutes (in my

opinion) were productive. There were solutions proposed, and I'd like to get
shared here in writing. Please invite more interested people and make them
aware of this list, and let's do the discussions here. I will do some
announcements on other lists to bring awareness to this list.


One proposal was that we could make sure
<> was available in end systems,
and this could be adapted by 802.11 as one way to help the APs handle
multicast load by letting them more easily identify how to turn multicast
packets into unicast packets.


Another proposal was to just do less multicast by redesigning IETF protocols
and how they behave.


WHen we're saying multicast here, we're talking L1/L2 multicast, ie sending
multicast/broadcast packets over wifi between devices connected to the same
L2 domain. This can be IPv6 ND/RA packets, but also service discover such as
Bonjour packets.


I would like to have the people who proposed the solutions to elaborate on
what their thinking was.






there is nothing concrete being proposed as far as I know. Alia indicated to
me she was still looking for a problem statement.


The problem statement I was involved in writing 2 years ago:







At the end there are multiple links to problem statements etc.


>From what I can tell, there is a problem. It's unclear what should be 


about it, if this is a IEEE problem to make sure wifi works well with
multicast, or if IETF should adapt its protocols to handle the way IEEE does
multicast over 802.11 without the special mechanisms for improved multicast
reliability that isn't widely implemented in currently shipping devices.


So I guess this is what we're supposed to consider.



Mcast-wifi mailing list