From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id CDBF221F3AF for ; Mon, 25 Aug 2014 00:43:17 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XLovq-0002k4-SO; Mon, 25 Aug 2014 09:43:14 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XLovq-0004sB-Fn; Mon, 25 Aug 2014 09:43:14 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: Date: Mon, 25 Aug 2014 09:43:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2BB30FF1-CF65-4562-AFC9-99F41693CA9C@ifi.uio.no> References: <20140824034935.7D41E406060@ip-64-139-1-69.sjc.megapath.net> To: David Lang X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 4 sum rcpts/h 13 sum msgs/h 5 total rcpts 19468 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4D20ACC933F820B9B655354967ACA493A9200B84 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 5872 max/h 17 blacklist 0 greylist 0 ratelimit 0 Cc: Hal Murray , bloat@lists.bufferbloat.net 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: Mon, 25 Aug 2014 07:43:18 -0000 On 24. aug. 2014, at 07:14, David Lang wrote: > On Sat, 23 Aug 2014, Hal Murray wrote: >=20 >>>> Yep... I remember a neat paper from colleagues at Trento University = that >>>> piggybacked TCP's ACKs on link layer ACKs, thereby avoiding the = collisions >>>> between TCP's ACKs and other data packets - really nice. Not sure = if it >>>> wasn't just simulations, though. >>=20 >>> that's a neat hack, but I don't see it working, except when one end = of the >>> wireless link is also the endpoint of the TCP connection (and then = only for >>> acks from that device) >>=20 >> That could be generalized to piggybacking any handy small packet onto = the >> link layer ACK. >>=20 >> Of course, then you have to send back a link layer ACK for the extra = info. >> Does that converge? >=20 > if you aren't talking between the two endpoints of the wireless = connection, probably :-) >=20 > but fairness would be an issue for something like this. what = constitues a 'small amount of data' to try and piggyback, and what = happens if you are talking between endpoints, are the two allowed to = monopolize the airtime? I agree - there'd have to be a size limit placed on what you really do = piggyback on link layer ACKs. TCP ACK size can vary, depending on = SACK... > but backing up a step, finding airtime for the ack is just as hard as = finding airtime for the next transmission. I think not, don't link layer ACKs get to use a smaller CW? Or is this = just me remembering it wrongly? Cheers, Michael