From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by huchra.bufferbloat.net (Postfix) with ESMTP id 4864221F524 for ; Sat, 23 Aug 2014 20:49:36 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 7D41E406060; Sat, 23 Aug 2014 20:49:35 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: bloat@lists.bufferbloat.net From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Aug 2014 20:49:35 -0700 Message-Id: <20140824034935.7D41E406060@ip-64-139-1-69.sjc.megapath.net> Cc: Hal Murray 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 03:49:36 -0000 >> 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. > 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) That could be generalized to piggybacking any handy small packet onto the link layer ACK. Of course, then you have to send back a link layer ACK for the extra info. Does that converge? -- These are my opinions. I hate spam.