From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 02CB221FA76; Sun, 9 Aug 2015 12:31:17 -0700 (PDT) Received: by ykdz80 with SMTP id z80so13253922ykd.2; Sun, 09 Aug 2015 12:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kic3twhZImuwKXSv26LFE7rR4YQDhH7lWNDhD5UTbmU=; b=wcxZvIiQ5npfs98XtwjjOuSR2KLvfdrwOdlPlSaxJfQFMjnpjpXm8KFTcJ+TYD+RXq ZcpKtyDeeOtLyaH13k01XQw5cvo18nESmCHmzobGSOza4tz8nfUCZ4KF+5yzeVFhz9b2 3E9erhGGtojips1iPGgm2NIa5MTtI3RDNJp5P2NLvblVOn7XwzSWCTqpzDaYbXLFBu+7 MvozsMnBCAf+t9XoUzcOZGJvjIecQpFMyNJ9BcaLmlbc0+lMY3nQhH+pHUaFelMduuK6 cKD2HGOLMqsBa/gEGK+ZoHonxq3zj0sdnJsIR814RM9nCLs9Lkex1QnRNJ7FUsViM5q4 OaHg== MIME-Version: 1.0 X-Received: by 10.170.131.12 with SMTP id x12mr18076301ykb.42.1439148676571; Sun, 09 Aug 2015 12:31:16 -0700 (PDT) Received: by 10.37.26.9 with HTTP; Sun, 9 Aug 2015 12:31:16 -0700 (PDT) Received: by 10.37.26.9 with HTTP; Sun, 9 Aug 2015 12:31:16 -0700 (PDT) In-Reply-To: References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> <6E08E48D-5D53-48E5-B088-2D1DB5E566AD@gmail.com> <1438983998.16576420@apps.rackspace.com> <1439066765.7348311@apps.rackspace.com> Date: Sun, 9 Aug 2015 22:31:16 +0300 Message-ID: From: Jonathan Morton To: David Lang Content-Type: multipart/alternative; boundary=001a11396ce0a56865051ce5e925 Cc: make-wifi-fast@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2015 19:31:46 -0000 --001a11396ce0a56865051ce5e925 Content-Type: text/plain; charset=UTF-8 The question of whether to aggregate under congested conditions is controversial, probably because it depends on complex conditions. There are arguments both for and against. It may be worth considering it as a risk/reward tradeoff. Given N packets (which for brevity I'll assume are equal MTU sized), the reward is obviously proportional to N. Risk however is calculated as probability * consequence. Assuming all packets in the aggregate are lost on collision, the risk of collision scales with L*N, where L is N plus the overhead of the TXOP. Under that argument, usually you should not aggregate if the probability of collision is high. However, if only one packet is lost due to collision with, for example, a small RTS probe which is not answered, the risk scales with L, which is sublinear compared to the reward relative to the amount of aggregation (especially at high data rates where the TXOP overhead is substantial). Under this assumption, aggregation is usually profitable even with a high collision probability, and results in overall higher efficiency whether or not collisions are likely. This is the difference between the typical 802.11n situation (one checksum per aggregate) and the mandatory 802.11ac capability of a checksum per packet. As long as you also employ RTS/CTS when appropriate, the possibility of collisions is no longer a reason to avoid aggregating. - Jonathan Morton --001a11396ce0a56865051ce5e925 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The question of whether to aggregate under congested conditi= ons is controversial, probably because it depends on complex conditions.=C2= =A0 There are arguments both for and against.

It may be worth considering it as a risk/reward tradeoff.=C2= =A0 Given N packets (which for brevity I'll assume are equal MTU sized)= , the reward is obviously proportional to N.=C2=A0 Risk however is calculat= ed as probability * consequence.

Assuming all packets in the aggregate are lost on collision,= the risk of collision scales with L*N, where L is N plus the overhead of t= he TXOP.=C2=A0 Under that argument, usually you should not aggregate if the= probability of collision is high.

However, if only one packet is lost due to collision with, f= or example, a small RTS probe which is not answered, the risk scales with L= , which is sublinear compared to the reward relative to the amount of aggre= gation (especially at high data rates where the TXOP overhead is substantia= l).=C2=A0 Under this assumption, aggregation is usually profitable even wit= h a high collision probability, and results in overall higher efficiency wh= ether or not collisions are likely.

This is the difference between the typical 802.11n situation= (one checksum per aggregate) and the mandatory 802.11ac capability of a ch= ecksum per packet.=C2=A0 As long as you also employ RTS/CTS when appropriat= e, the possibility of collisions is no longer a reason to avoid aggregating= .

- Jonathan Morton

--001a11396ce0a56865051ce5e925--