From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (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 DE0A121FE49; Fri, 31 Jul 2015 10:04:01 -0700 (PDT) Received: by ykay190 with SMTP id y190so64067479yka.3; Fri, 31 Jul 2015 10:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nep3ghehPRJoLEtmRMOkRG3Ysp1Q3i2e9W6e/Fbme0E=; b=1EcmRXgdZgkKtyRzLp9iBV9OvaAw+SRGnBxljcgJo+HKFHbK4mgSM7COrcNYd4puiV RcgNZOj0aWMG/x4IY9/CZ1wA0P3Kt6RdIZb4uNPSpStgVk2e/THxQAkXpERCipJw6jZg AwaPWd/47eWA3bWG+K8VZQg4afMDOvTVTeb1qWAPadMLMXOU9XzYh2fR0qfib3MZ9UQu 4b0ftJJZZuN2LXTnxTU4Vn1BryzUoW7AbQYyPIncLv80a02aG4C5EJowMxdqmKldD4Ea qL7WXkx7LhOj5qo3ho+aIFTqb0dRsp0kkbuBEr/IehOiZ3HMxtgji0ZO96v+HcI8/GhI k82Q== MIME-Version: 1.0 X-Received: by 10.170.70.66 with SMTP id m63mr4402181ykm.72.1438362240379; Fri, 31 Jul 2015 10:04:00 -0700 (PDT) Received: by 10.37.26.9 with HTTP; Fri, 31 Jul 2015 10:04:00 -0700 (PDT) Received: by 10.37.26.9 with HTTP; Fri, 31 Jul 2015 10:04:00 -0700 (PDT) In-Reply-To: <1438361254.45977158@apps.rackspace.com> References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> Date: Fri, 31 Jul 2015 20:04:00 +0300 Message-ID: From: Jonathan Morton To: "David P. Reed" Content-Type: multipart/alternative; boundary=001a1139cf146572cb051c2ecef9 Cc: make-wifi-fast@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 17:04:30 -0000 --001a1139cf146572cb051c2ecef9 Content-Type: text/plain; charset=UTF-8 > I think that is achievable, *even if there is a WiFi network in the middle*, by thinking about the fact that the shared airwaves in a WiFi network behaves like a single link, so all the queues on individual stations are really *one queue*, and that the optimal behavior of that link will be achieved if there is at most one packet queued at a time. I agree that queues should be kept short in general. However I don't think single packet queues are achievable in the general case. The general case includes Wi-Fi networks, whose TXOP overhead is so ruinously heavy that sending single MTU sized packets is inefficient. Aggregating multiple packets into one TXOP requires those several packets to be present in the buffer at that moment. The general case includes links which vary in throughput frequently, perhaps on shorter timescales than an RTT, so either packets must be buffered or capacity is left unused. This also happens to include Wi-Fi, but could easily include a standard wired link whose competing load varies. The endpoints do not have and do not receive sufficient information in sufficient time to reliably make packets arrive at nodes just in time to be transmitted. Not even with ECN, not even with the wet dreams of the DCTCP folks, and not even with ELR (though ELR should be able to make it happen under steady conditions, there are still transient conditions in the general case). - Jonathan Morton --001a1139cf146572cb051c2ecef9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> I think that is achievable, *even if there is a WiFi ne= twork in the middle*, by thinking about the fact that the shared airwaves i= n a WiFi network behaves like a single link, so all the queues on individua= l stations are really *one queue*, and that the optimal behavior of that li= nk will be achieved if there is at most one packet queued at a time.

I agree that queues should be kept short in general. However= I don't think single packet queues are achievable in the general case.=

The general case includes Wi-Fi networks, whose TXOP overhea= d is so ruinously heavy that sending single MTU sized packets is inefficien= t. Aggregating multiple packets into one TXOP requires those several packet= s to be present in the buffer at that moment.

The general case includes links which vary in throughput fre= quently, perhaps on shorter timescales than an RTT, so either packets must = be buffered or capacity is left unused. This also happens to include Wi-Fi,= but could easily include a standard wired link whose competing load varies= .

The endpoints do not have and do not receive sufficient info= rmation in sufficient time to reliably make packets arrive at nodes just in= time to be transmitted. Not even with ECN, not even with the wet dreams of= the DCTCP folks, and not even with ELR (though ELR should be able to make = it happen under steady conditions, there are still transient conditions in = the general case).

- Jonathan Morton

--001a1139cf146572cb051c2ecef9--