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, 09 Apr 2017 13:15:00 +0200
From: Linus Lüssing <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
- Re: [Int-area] [pim] Fwd: [ieee-ietf-coord] draft… Linus Lüssing
- Re: [Int-area] [pim] Fwd: [ieee-ietf-coord] draft… Linus Lüssing