From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (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 46B6921F356 for ; Sun, 31 Aug 2014 15:35:35 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s7VMZQoe003502; Sun, 31 Aug 2014 15:35:27 -0700 Date: Sun, 31 Aug 2014 15:35:26 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Michael Welzl In-Reply-To: <8C18A920-D0A8-4052-85EC-FF6D6039FD53@ifi.uio.no> Message-ID: References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <64CD1035-2E14-4CA6-8E90-C892BAD48EC6@netapp.com> <4C1661D0-32C6-48E7-BAE6-60C98D7B2D69@ifi.uio.no> <8C18A920-D0A8-4052-85EC-FF6D6039FD53@ifi.uio.no> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: bloat 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, 31 Aug 2014 22:35:35 -0000 On Mon, 25 Aug 2014, Michael Welzl wrote: >> But this cache of recently sent packets is separate from a queue of packets waiting to be sent. >> >> the size of the buffer used to track what's been sent isn't a problem. the >> bufferbloat problem is aroudn the size of the queue for packet waiting to be >> sent. > > This confuses me. Why do you even need a cache of recently sent packets? so that you can re-send them. if you are the originator of the packet, you need to have this. If your are relaying packets over some media that has link-level acks you need this for all packets you relay as well > Anyway, what I am talking about *is* the size of the queue for packets waiting > to be sent - and not only due to aggregation but also link layer retransmits. > Per device, at the link layer, packets (frames, really) are sent in sequence > AFAIK, and so any frame that has been sent but not yet acknowledged and then > has to be resent if it isn't acknowledged holds up all other frames to that > same destination. > > > >>>> If people are retrying when they really don't need to, that cuts down on the avialable airtime. >>> >>> Yes >>> >>> >>>> But if you have continual transmissions taking place, so you have a hard time getting a chance to send your traffic, then you really do have congestion and should be dropping packets to let the sender know that it shouldn't try to generate as much. >>> >>> Yes; but the complexity that I was pointing at (but maybe it's a simple parameter, more like a 0 or 1 situation in practice?) lies in the word "continual". How long do you try before you decide that the sending TCP should really think it *is* congestion? To really optimize the behavior, that would have to depend on the RTT, which you can't easily know. >> >> Again, I think you are mixing two different issues here. > > No, I think you misunderstand me - > > >> 1. waiting for a pause in everyone else's transmissions so that you can >> transmit wihtout _knowing_ that you are going to clobber someone >> >> Even this can get tricky, is that station you are hearing faintly trying to >> transmit to a AP near you so you should be quiet? or is it transmitting to a >> station enough further away from you so you can go ahead and transmit your >> packet to your AP without interfering with it? > > You mean the normal CSMA/CA procedure ( + RTS/CTS)? Sure that's tricky in > itself but I wasn't talking about that. > > >> 2. your transmission gettng clobbered so the packet doesn't get through, >> where you need to wait 'long enough' to decide that it's not going to be >> acknowledged and try again. > > I was always only talking about that second bit. I'm sure I wasn't clear > enough in writing and I'm sorry for that. > > >> This is a case where a local proxy server can actually make a big difference >> to you. The connections between your mobile devices and the local proxy >> server have a short RTT and so all timeouts can be nice and short, and then >> the proxy deals with the long RTT connections out to the Internet. > > Adding a proxy to these considerations only complicates them: it's a hard > enough trade-off when we just ask ourselves: how large should a buffer for the > sake of link layer retransmissions be? (which is closely related to the > question: how often should a link layer try to retransmit before giving up?) > That's what my emails were about. I suspect that we don't have a good answer > to even these questions, and I suspect that we'd better off having something > dynamic than fixed default values. A proxy should simplify this, because the total connection RTT now is client <-> AP <-> proxy, not client <-> AP <-> Internet <-> server. if you can _know_ that the endpoint of the connection is a local proxy that's only 10ms away, you don't need to have timeouts long enough to handle a multi-second connection to a server on the other side of the world with you both using satellite links David Lang