Re: [Int-area] [pim] Fwd: [ieee-ietf-coord] draft on Multicast Considerations over IEEE 802 Wireless Media

Linus Lüssing <linus.luessing@c0d3.blue> Sun, 09 April 2017 11:15 UTC

Return-Path: <linus.luessing@c0d3.blue>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB95E1293EB; Sun, 9 Apr 2017 04:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be22tw9OWN4b; Sun, 9 Apr 2017 04:15:06 -0700 (PDT)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [IPv6:2a01:4f8:171:314c::100:a1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D290126BF0; Sun, 9 Apr 2017 04:15:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aperture-lab.de (Postfix) with ESMTP id 82EA2E24CA; Sun, 9 Apr 2017 13:15:03 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at aperture-lab.de
Received: from mail.aperture-lab.de ([127.0.0.1]) by localhost (mail.aperture-lab.de [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 9ENmGiwTlkJt; Sun, 9 Apr 2017 13:15:03 +0200 (CEST)
Received: from localhost (unknown [IPv6:2001:67c:2d50:0:c85:8cff:fe0f:63fe]) (Authenticated sender: linus.luessing@c0d3.blue) by mail.aperture-lab.de (Postfix) with ESMTPSA; Sun, 9 Apr 2017 13:15:02 +0200 (CEST)
Date: Sun, 9 Apr 2017 13:15:00 +0200
From: Linus =?utf-8?Q?L=C3=BCssing?= <linus.luessing@c0d3.blue>
To: int-area@ietf.org
Cc: j.c.zuniga@ieee.org, draft-perkins-intarea-multicast-ieee802@ietf.org, "Alvaro Retana (aretana)" <aretana@cisco.com>
Message-ID: <20170409111500.GF10335@otheros>
References: <CAHLBt81QW3MCXp3EdGEn3TEVgghJYpCdXguUZhROvE9zZnvfNw@mail.gmail.com> <6464383E-6F47-4890-982E-3ADA9ADE80B3@cisco.com> <20170409103716.GE10335@otheros>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20170409103716.GE10335@otheros>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/6Di_MSLJKrlq1hRs4IjbI00Y45E>
Subject: Re: [Int-area] [pim] Fwd: [ieee-ietf-coord] draft on Multicast Considerations over IEEE 802 Wireless Media
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Apr 2017 11:15:07 -0000

On Sun, Apr 09, 2017 at 12:37:16PM +0200, Linus Lüssing wrote:
> An older version of OpenWRT missed RFC4541 for its group-aware
> multicast-to-unicast implementation some years ago entirely,
> resulting in ugly packetloss back then...

By the way, the according (fixed/working :) ) patch got accepted
upstream in the Linux kernel just recently. There had been quite some
discussions on the according mailinglists, because the according
patch was basically hijacking the Linux bridge code (the "software
switch" implementation in Linux which conveniently already
provided IGMP/MLD snooping). Also, there was a submission at the
same time for a non-group-aware multicas-to-unicast patch which was
done entirelly in the Linux wireless stack though.

So there were some thoughts and discussions on moving smartness more
into the Linux wireless stack.

Regarding the IETF-IEEE coordination I would be curious to
know how much smartness to implement into a generic wireless stack
makes sense.

For instance, does it make sense to implement some group-aware, QoS-aware,
clever algorithm in a wireless stack to convert a multicast packet to a
mix of multicast and unicast frames to be transmitted at various, selected
802.11 bitrates? Or will wifi chips be able to provide a superior,
more convenient solution in the future?

Regards, Linus