Re: [ipwave] QoS Data vs. Data for IPv6 over 802.11-OCB - implementation aspects
Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 17 October 2019 09:39 UTC
Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147E5120824 for <its@ietfa.amsl.com>; Thu, 17 Oct 2019 02:39:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 mYeinc923veV for <its@ietfa.amsl.com>; Thu, 17 Oct 2019 02:39:56 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55F7120088 for <its@ietf.org>; Thu, 17 Oct 2019 02:39:55 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9H9drPM035610; Thu, 17 Oct 2019 11:39:53 +0200
Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A0BC8202471; Thu, 17 Oct 2019 11:39:53 +0200 (CEST)
Received: from pisaure by pisaure with queue id 7347740-2; Thu, 17 Oct 2019 09:39:53 GMT
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 73ACB200BF0; Thu, 17 Oct 2019 11:39:53 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9H9drFd019617; Thu, 17 Oct 2019 11:39:53 +0200
To: its@ietf.org
References: <29da193f-51bc-3741-5185-62d4e247c3e5@ing.uchile.cl> <fbf17ba9-dd45-efad-6fae-f3ff3556f9b9@ing.uchile.cl>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: "Sandra Céspedes U." <scespedes@ing.uchile.cl>, Mariama SARR <mariama.sarr@cea.fr>
Message-ID: <577f7b13-f111-b2e6-1c68-ecc245ba534a@gmail.com>
Date: Thu, 17 Oct 2019 11:39:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <fbf17ba9-dd45-efad-6fae-f3ff3556f9b9@ing.uchile.cl>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/xOFlUGmWGnuw67Zpt5gbQQH-IcI>
Subject: Re: [ipwave] QoS Data vs. Data for IPv6 over 802.11-OCB - implementation aspects
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 09:39:59 -0000
Hi IPWAVErs, I take advantage of the email from Sandra reporting about the use of QoS Data headers for IP in Arada Systems. We would like to make QoS Data headers for IP on OCB work on open source, because that is what the Internet Draft IPv6-over-OCB requires ("The mapping to the 802.11 data service SHOULD use a 'priority' value of 1 (QoS with a 'Background' user priority)"). It is a long term goal. We did some progress. The most promissing result is maybe that ath10k _might_ work with QoS Data headers with IPv6 on OCB. At this time we stopped trying to make QoS Data headers with IP on OCB work on open source. Is somebody else working in the same aspects and who is more advanced than us in this study? Do you know if it is possible to implement QoS data header on ATH9K? If yes is it possible to give us some technical details? If not is it possible to know what are the technical limits? How about ATH10K, is there any work in progress in this direction? Here's what we tried: 0. we have a partner in Greece who specializes in making OCB cards with MArvell. They worked with us from this WG, and with someone from Marvell, and from IEEE, to put a Marvell 88W8997 card, on a LAIRD module, a Manufacturer's Firmware, (MFW), at 5.9 GHz. But that is still in a sort of simulator or 'sandbox' state in linux, that, even if it works, it does not really put packets in the air. This result is of January 2019. 1. we tried to set the flow label on IPv6 base header, by using a python code from https://github.com/nasa/ipv6_python. We hoped that setting the flow label it would automagically set the QoS Data headers. But the result of this script is that the flow label changes at each packet and, worse, there is no QoS Data header added at all. It is still the Data header that is set. 2. we tried to find options in the linux kernel (make menuconfig) that have the 'qos' name in some WiFi section. In kernel 4.4.0 and 5.2.2 we found Symbols 'IPW2200_QOS' (Intel PRO/Wireless 2200BG...) and 'DWMAC_DWC_QOS_ETH' (ST, Qualcomm, Intel) respectively. But these are specific to these manufacturers, and supposedly would not work with manufacturer Atheros (ath9k) nor with the generic MAC80211. And it is this ath9k driver that has open source OCB support (ST/Qualcomm/Intel dont do OCB). Because of that, we were reluctant to set these QoS options on them. We tried, half-heartedly, only to notice that the packets still dont get QoS Data headers. It is understandable, because our cards are ath9k in OCB mode and not Intel/ST/Qualcomm. 3. we searched for 'qos', 'qos-data' and 'qos_data' throughout the entire kernel source code, and tried to reduce the results to only what is pertinent to WiFi (eliminate Ethernet, ATM and others). For some Atheros drivers, we could guess that QoS is partly implemented. At this time we do not know how this works because we don't have right drivers to test (need ath10k like 802.11ac). Worse - we don't really understand how QoS implementation works. We can guess that it is possible to implement QoS Data header with a ATH10K driver, but we are not 100% sur about that. I suppose that if we get an OCB mode with ath10k driver then not only we get QoS Data headers, but we get also higher bandwidth of IPv6 on OCB. This might be very helpful for many V2V communications involving video (needs high bandwidth low latency). This is the raw output of the search results for QoS related to wifi in Atheros in kernel: Ath5K : ath/ath5k/base.c: if (ieee80211_is_data_qos(frame_control)) Ath6kl (for debugging?): th/ath6kl/wmi.c: hdr_size = roundup(sizeof(struct ieee80211_qos_hdr), ath/ath6kl/wmi.c: * for delete qos stream from AP ath/ath6kl/debug.c:static ssize_t ath6kl_create_qos_write(struct file *file, ath/ath6kl/debug.c:static const struct file_operations fops_create_qos = { ath/ath6kl/debug.c: .write = ath6kl_create_qos_write, ath/ath6kl/debug.c:static ssize_t ath6kl_delete_qos_write(struct file *file, ath/ath6kl/debug.c:static const struct file_operations fops_delete_qos = { ath/ath6kl/debug.c: .write = ath6kl_delete_qos_write, ath/ath6kl/debug.c: debugfs_create_file("create_qos", S_IWUSR, ar->debugfs_phy, ar, ath/ath6kl/debug.c: &fops_create_qos); ath/ath6kl/debug.c: debugfs_create_file("delete_qos", S_IWUSR, ar->debugfs_phy, ar, ath/ath6kl/debug.c: &fops_delete_qos); Ath9k (need to deepen and to understand what is done): ath/ath9k/recv.c: !ieee80211_is_qos_nullfunc(hdr->frame_control)) ath/ath9k/htc_drv_txrx.c: if (ieee80211_is_data_qos(hdr->frame_control)) { ath/ath9k/htc_drv_txrx.c: qc = ieee80211_get_qos_ctl(hdr); ath/ath9k/htc_drv_txrx.c: if (ieee80211_is_data_qos(fc)) { ath/ath9k/htc_drv_txrx.c: qc = ieee80211_get_qos_ctl(hdr); ath/ath9k/hw.c:static void ath9k_hw_init_qos(struct ath_hw *ah) ath/ath9k/hw.c: ath9k_hw_init_qos(ah); Ath10k (the implementation seems to be more quantitative than for ath9k and it is done on mac layer, which is what we need) ath/ath10k/htt.c: 36 + /* 802.11 + qos + ht */ ath/ath10k/wmi.c: .pmf_qos = WMI_PDEV_PARAM_PMF_QOS, ath/ath10k/wmi.c: .pmf_qos = WMI_10X_PDEV_PARAM_PMF_QOS, ath/ath10k/wmi.c: .pmf_qos = WMI_10X_PDEV_PARAM_PMF_QOS, ath/ath10k/wmi.c: .pmf_qos = WMI_10_4_PDEV_PARAM_PMF_QOS, ath/ath10k/mac.c:static int ath10k_peer_assoc_qos_ap(struct ath10k *ar, ath/ath10k/mac.c:static void ath10k_peer_assoc_h_qos(struct ath10k *ar, ath/ath10k/mac.c: if (vif->bss_conf.qos) ath/ath10k/mac.c: ath10k_dbg(ar, ATH10K_DBG_MAC, "mac peer %pM qos %d\n", ath/ath10k/mac.c: ath10k_peer_assoc_h_qos(ar, vif, sta, arg); ath/ath10k/mac.c: ret = ath10k_peer_assoc_qos_ap(ar, arvif, sta); ath/ath10k/mac.c: ath10k_warn(ar, "failed to set qos params for STA %pM for vdev %i: %d\n", ath/ath10k/mac.c: if (!ieee80211_is_data_qos(hdr->frame_control)) ath/ath10k/mac.c: return ieee80211_get_qos_ctl(hdr)[0] & IEEE80211_QOS_CTL_TID_MASK; ath/ath10k/mac.c: (ieee80211_is_nullfunc(fc) || ieee80211_is_qos_nullfunc(fc)) && ath/ath10k/mac.c: u8 *qos_ctl; ath/ath10k/mac.c: if (!ieee80211_is_data_qos(hdr->frame_control)) ath/ath10k/mac.c: qos_ctl = ieee80211_get_qos_ctl(hdr); ath/ath10k/mac.c: skb->data, (void *)qos_ctl - (void *)skb->data); ath/ath10k/mac.c: if (ieee80211_is_qos_nullfunc(hdr->frame_control)) ath/ath10k/mac.c: ret = ath10k_wmi_pdev_set_param(ar, ar->wmi.pdev_param->pmf_qos, 1); ath/ath10k/rx_desc.h: * non_qos ath/ath10k/wmi-tlv.h: __le32 peer_qos; ath/ath10k/htt.h: * ext_tid: for qos-data frames (0-15), see %HTT_DATA_TX_EXT_TID_ ath/ath10k/htt.h: __le32 deliver_non_qos; ath/ath10k/wmi.h: u32 pmf_qos; ath/ath10k/wmi-tlv.c:static u32 ath10k_wmi_tlv_prepare_peer_qos(u8 uapsd_queues, u8 sp) ath/ath10k/wmi-tlv.c: u32 peer_qos = 0; ath/ath10k/wmi-tlv.c: peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_VO; ath/ath10k/wmi-tlv.c: peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_VI; ath/ath10k/wmi-tlv.c: peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_BK; ath/ath10k/wmi-tlv.c: peer_qos |= WMI_TLV_TDLS_PEER_QOS_AC_BE; ath/ath10k/wmi-tlv.c: peer_qos |= SM(sp, WMI_TLV_TDLS_PEER_SP); ath/ath10k/wmi-tlv.c: return peer_qos; ath/ath10k/wmi-tlv.c: u32 peer_qos; ath/ath10k/wmi-tlv.c: peer_qos = ath10k_wmi_tlv_prepare_peer_qos(cap->peer_uapsd_queues, ath/ath10k/wmi-tlv.c: peer_cap->peer_qos = __cpu_to_le32(peer_qos); ath/ath10k/wmi-tlv.c: .pmf_qos = WMI_TLV_PDEV_PARAM_PMF_QOS, ath/ath10k/htt_rx.c: if (!ieee80211_is_data_qos(hdr->frame_control)) ath/ath10k/htt_rx.c: qc = ieee80211_get_qos_ctl(hdr); ath/ath10k/htt_rx.c: u8 *qos; ath/ath10k/htt_rx.c: qos = ieee80211_get_qos_ctl(hdr); ath/ath10k/htt_rx.c: qos[0] &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT; Carl9170 ath/carl9170/rx.c: if (ieee80211_is_data_qos(hdr->frame_control)) { ath/carl9170/rx.c: u8 *qc = ieee80211_get_qos_ctl(hdr); ath/carl9170/rx.c: if (ieee80211_is_data_qos(fc) && ieee80211_is_data_present(fc)) ath/carl9170/mac.c:int carl9170_set_qos(struct ar9170 *ar) ath/carl9170/debug.c:static char *carl9170_debugfs_qos_stat_read(struct ar9170 *ar, char *buf, ath/carl9170/debug.c:DEBUGFS_DECLARE_RO_FILE(qos_stat, 512); ath/carl9170/debug.c: DEBUGFS_ADD(qos_stat); ath/carl9170/carl9170.h: /* qos queue settings */ ath/carl9170/carl9170.h:int carl9170_set_qos(struct ar9170 *ar); ath/carl9170/carl9170.h: return (ieee80211_get_qos_ctl(hdr))[0] & IEEE80211_QOS_CTL_TID_MASK; ath/carl9170/wlan.h: u8 qos_queue:2; ath/carl9170/main.c: err = carl9170_set_qos(ar); ath/carl9170/main.c: ret = carl9170_set_qos(ar); Wnc36xx ath/wcn36xx/txrx.c: if (WARN_ON(!ieee80211_is_data_qos(hdr->frame_control))) ath/wcn36xx/txrx.c: qc = ieee80211_get_qos_ctl(hdr); ath/wcn36xx/txrx.c: bool is_data_qos; ath/wcn36xx/txrx.c: is_data_qos = ieee80211_is_data_qos(hdr->frame_control); ath/wcn36xx/txrx.c: is_data_qos ? ath/wcn36xx/txrx.c: sizeof(struct ieee80211_qos_hdr) : ath/wcn36xx/txrx.c: if (sta_priv && is_data_qos) ath/wcn36xx/txrx.c: ieee80211_is_data_qos(hdr->frame_control) ? ath/wcn36xx/txrx.c: sizeof(struct ieee80211_qos_hdr) : Le 10/10/2019 à 16:41, Sandra Céspedes U. a écrit : > Dear all, > > Here at Niclabs, Universidad de Chile, we have been playing with some > commercial RSU and OBUs we use for research purposes. I asked my > students to capture traffic from basic IP exchanges to confirm the type > of encapsulation at the link layer. If you check the report below (I > have also included the pcap files), they confirm that all the IP packets > are encapsulated as QoS Data. > > I'm providing the files to have more evidence of what the commercial > vendors are doing in their implementations. > > Hope you find them useful. > > Best, > Sandra Céspedes > > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > _______________________________________________ > its mailing list > its@ietf.org > https://www.ietf.org/mailman/listinfo/its >
- [ipwave] QoS Data vs. Data for IPv6 over 802.11-O… Sandra Céspedes U.
- Re: [ipwave] QoS Data vs. Data for IPv6 over 802.… Alexandre Petrescu
- Re: [ipwave] QoS Data vs. Data for IPv6 over 802.… Alexandre Petrescu
- Re: [ipwave] QoS Data vs. Data for IPv6 over 802.… Alexandre Petrescu