From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-11-iad.dyndns.com (mxout-064-iad.mailhop.org [216.146.32.64]) by lists.bufferbloat.net (Postfix) with ESMTP id 5F83D2E03C0 for ; Wed, 16 Mar 2011 13:08:12 -0700 (PDT) Received: from scan-11-iad.mailhop.org (scan-11-iad.local [10.150.0.208]) by mail-11-iad.dyndns.com (Postfix) with ESMTP id 8BC511713DE for ; Wed, 16 Mar 2011 20:08:11 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.161.43 Received: from mail-fx0-f43.google.com (mail-fx0-f43.google.com [209.85.161.43]) by mail-11-iad.dyndns.com (Postfix) with ESMTP id DFC941713CF for ; Wed, 16 Mar 2011 20:08:10 +0000 (UTC) Received: by fxm3 with SMTP id 3so2545754fxm.16 for ; Wed, 16 Mar 2011 13:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=jzIRCGVCe9KpwoMl5WSqEeuG8jDVvMmhxMwAwSRCpyw=; b=lBXi8+OwsGUSeO45R3abm+4GpZjglDFDDl5ELVWyBHxzFq4xvWUTR2zY8vWM5HUbU7 Adphfy6RMlsCuPhYZ2uPDHCfnnU40uYVMVvDYZubOoW4s8+yqIHJKkqe2HamSbZOuTjU njd23QwCMjf2VdCqE1h+mDteQmTXSLbxbpixI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=cJ0sBaCXo6Ih/k6762qAJjTJ9e7CtNHgP6h5xM49uaXiGBnkhxk6U6qrTmRCrJrd4E R4CS5OsQ1xhekpUfT/hGo0LITHOjYFv2+UCUaB0lpszN4+/soOJi99ZCeb+8jLz5UzpE EYzVXPyQsPzAL2P4qO9xQP6TiSCTPULDnShuc= MIME-Version: 1.0 Received: by 10.223.57.206 with SMTP id d14mr435039fah.143.1300306061952; Wed, 16 Mar 2011 13:07:41 -0700 (PDT) Sender: gettysjim@gmail.com Received: by 10.223.71.201 with HTTP; Wed, 16 Mar 2011 13:07:41 -0700 (PDT) In-Reply-To: <20110316004722.GD28663@tuxdriver.com> References: <4D7F4121.40307@freedesktop.org> <20110315175942.GA10064@goldfish> <1300212877.2087.2155.camel@tardy> <20110315183111.GB2542@tuxdriver.com> <29B06777-CC5F-4802-8727-B04F58CDA9E3@gmail.com> <20110315205146.GF2542@tuxdriver.com> <219C7840-ED79-49EA-929D-96C5A6200401@gmail.com> <20110316004722.GD28663@tuxdriver.com> Date: Wed, 16 Mar 2011 16:07:41 -0400 X-Google-Sender-Auth: 8ipRVt5LhkFCSDvF0CTLyHgDdto Message-ID: From: Jim Gettys To: "John W. Linville" , bloat@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps? 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: Wed, 16 Mar 2011 20:08:12 -0000 On Tue, Mar 15, 2011 at 8:47 PM, John W. Linville wrote: > > If you count mac80211 as part of the "driver", what is between the > qdisc and the "driver"? =A0I wouldn't consider the bottom of the qdisc > as the core of the stack. > > I would really like to see eBDP (or ALT or A* or something similar) > implemented in a single place if possible, rather than reimplemented > (perhaps poorly) in a series of drivers. =A0I know Felix and others think > that 802.11n aggregation makes that impossible, but I'm inclined to > think that is still at least partly from a bias towards throughput > at the expense of latency -- I could be wrong! :-) I'm told by our cell phone wireless people there are similar concerns for the wireless cellular technologies; in their case =A0I encouraged them strongly today to join the mailing list. Let's also distinguish between "can't do it with today's broken hardware" (of which there is almost certainly an ample supply), and having a solution that can work when the hardware is cooperative. "(2) Less well known to non-cellular folks is the fact that the *full buffer* packet data cell throughput of EVDO or HSPA is noticeably higher than that with *bursty* traffic at decent load. Part of it is due to (1) =A0above but a second part is due to the fact that each cellular link is =A0made more efficient through multi-user diversity gain that exploits fading channel peaks of independent users while still utilizing the link fully provided there are enough users - my point is, such gains dilute when a user enjoying a channel peak doesn't have data waiting in his buffer at that time... It helps to keep users' buffers non-empty from this perspective..." As I pointed out to them, it may (or may not) be that things just work out well; if the channel is busy, you'll have more time for aggregation of packets to naturally occur. =A0We don't need to run the channel efficiently when the channel isn't saturated. =A0Whenever the air isn't busy, it doesn't matter if we don't bother to aggregate. Who knows what those driver interfaces look like at this point? =A0Has anyone tried to grok what's in Android for those drivers (if enough of the source is available to them to be useful...) - Jim