From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x242.google.com (mail-la0-x242.google.com [IPv6:2a00:1450:4010:c03::242]) (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 CE1C621F4F7 for ; Sun, 24 Aug 2014 02:20:32 -0700 (PDT) Received: by mail-la0-f66.google.com with SMTP id mc6so4023077lab.9 for ; Sun, 24 Aug 2014 02:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jy6hdYzAQ+VA7QYFdat0uFtqZaBYTk5TKpomZZG0sq0=; b=DMTkUlk2gq6CtcstEBrMFA2Ws+pUssDRTeQHIcAogin6Oy7/Z9US+/hhIMVqREgkIb 6Ob6+N5s7TPgpMHCOZ3do2elX9PqRhXkbNbtiukgtNC5D6uXcsIjW1DFpdLCDM9O1ZzT sUvlwDWYzQtoATjb28v0iQQzjYBMFEljGk24l1hIRW5cEQToOwIrROc/hMzK9mSh+CDF ygiZx7SnK81Ff2yVuOkW8dAD+8DBd9jGi8WNeYLR0jwNv6jO3K+sfl4gJCObUKeqgc0F 8cOO3dls2g8q5Ozk2rpoBvO/hBHrW9nGSWtoXL0kb39Oj82iYd+yXis+1wXa3+6gGJB0 HtCg== X-Received: by 10.152.44.162 with SMTP id f2mr953115lam.84.1408872030293; Sun, 24 Aug 2014 02:20:30 -0700 (PDT) Received: from bass.home.chromatix.fi (178-55-54-191.bb.dnainternet.fi. [178.55.54.191]) by mx.google.com with ESMTPSA id r5sm14560160lah.3.2014.08.24.02.20.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Aug 2014 02:20:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Jonathan Morton In-Reply-To: Date: Sun, 24 Aug 2014 12:20:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2D60CE42-D1E4-48B0-83E3-6A4188F34BE4@gmail.com> References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> <4C1661D0-32C6-48E7-BAE6-60C98D7B2D69@ifi.uio.no> <8651E326-171F-472F-9456-920A9E43367D@gmail.com> <4265A8B2-10DA-455A-BA61-41907752365D@gmail.com> <5DEDBF8E-EA25-4CEC-B235-1F0122CAB228@gmail.com> To: David Lang X-Mailer: Apple Mail (2.1085) Cc: bloat Mainlinglist Subject: Re: [Bloat] sigcomm wifi X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 09:20:33 -0000 On 24 Aug, 2014, at 11:24 am, David Lang wrote: > but it is a lot larger than simple packet size would indicate, because = the encapsulation per transmission is a fixed size (and no, I don't know = how large it is) I found a reference to the preamble/header format of 802.11a/g. Under = ideal conditions with default settings, the preamble+header of the PPDU = is transmitted at 6Mbps and takes about 50=B5s; the PSDU adds a further = 18=B5s overhead; a 4500-byte payload would then take 667=B5s to transmit = at 54Mbps. (Except that 'g' doesn't support a payload that big.) So even with a fairly large aggregated payload, and ignoring RTS/CTS, = the overhead is several percent. A 64-byte packet takes only 10=B5s to = send at that speed, so that 68=B5s overhead looks really nasty even at = lower speeds. And even that assumes that there aren't any 'b' devices = associated, which would cause the whole network to fall back to 96=B5s = 'b' preambles. That document doesn't even mention RTS/CTS/ACK. I found another diagram = which points out that each of these takes 30=B5s to send, including 10=B5s= periods of silence. So that's 90+68+10 =3D 168=B5s to send a 64-byte = packet, and 90+68+222 =3D 380=B5s to send a 1500-byte packet - only = twice as long. = http://ict.siit.tu.ac.th/~sgordon/its413y12s2/unprotected/ITS413Y12S2H22-D= CF-RTS-Three-Stations-Hidden.png The practical upshot - for 802.11a/g, a TCP ack costs roughly half as = much channel time as a full data packet. An ack every three packets, = with no aggregation on the data packets, would consume one-seventh (14%) = of the channel time. It's not as high as my previous estimate, but it's = still significant - and it backs up my hunch that simply negotiating for = the channel is a big enough overhead to talk about separately. - Jonathan Morton