From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp83.iad3a.emailsrvr.com (smtp83.iad3a.emailsrvr.com [173.203.187.83]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A60A43CB40 for ; Wed, 19 Oct 2022 17:26:32 -0400 (EDT) Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DDA4B210F2; Wed, 19 Oct 2022 17:26:31 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app40.wa-webapps.iad3a (Postfix) with ESMTP id C7DBB6107B; Wed, 19 Oct 2022 17:26:31 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 19 Oct 2022 17:26:31 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Wed, 19 Oct 2022 17:26:31 -0400 (EDT) From: "David P. Reed" To: "David Lang" Cc: "Bob McMahon" , "Cake List" , "Make-Wifi-fast" , "Bob McMahon via Rpm" , "bloat" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20221019172631000000_33111" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <6710sq51-1151-s739-qq87-0r5264qrs9q8@ynat.uz> <6697ss38-s3nr-99n3-8q5o-p24q6q7923np@ynat.uz> X-Client-IP: 209.6.168.128 Message-ID: <1666214791.81584918@apps.rackspace.com> X-Mailer: webmail/19.0.22-RC X-Classification-ID: 00d56ed1-1670-48f4-a471-59a1907587ec-1-1 Subject: Re: [Make-wifi-fast] [Cake] [Rpm] [Bloat] The most wonderful video ever about bufferbloat X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2022 21:26:32 -0000 ------=_20221019172631000000_33111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A4 microseconds!=0A =0AOn Wednesday, October 19, 2022 3:23pm, "David Lang= via Cake" said:=0A=0A=0A=0A> you have to list= en and hear nothing for some timeframe before you transmit, that=0A> listen= ing time is define in the standard. (isn't it??)=0A> =0A> David Lang=0A> = =0A> On Wed, 19 Oct 2022, Bob McMahon wrote:=0A> =0A> > I'm not sure where = the gap in milliseconds is coming from. EDCA gaps are=0A> > mostly driven b= y probabilities=0A> > . If=0A> > energy detect (ED) indicates the medium is available th= en the gap prior to=0A> > transmit, assuming no others competing & winning = at that moment in time, is=0A> > driven by AIFS and the CWMIN - CWMAX back = offs which are simple probability=0A> > distributions. Things change a bit = with 802.11ax and trigger frames but the=0A> > gap is still determined by t= he backoff and should be less than milliseconds=0A> > per that. Things like= NAVs will impact the gap too but that happens when=0A> > another is transm= itting.=0A> >=0A> >=0A> > [image: image.png]=0A> >=0A> > Agreed that the PL= CP preamble is at low MCS and the payload can be orders=0A> > of magnitude = greater (per different QAM encodings and other signal=0A> > processing tech= niques.)=0A> >=0A> > Bob=0A> >=0A> > On Wed, Oct 19, 2022 at 12:09 AM David= Lang wrote:=0A> >=0A> >> On Tue, 18 Oct 2022, Sebastian Mo= eller wrote:=0A> >>> Hi Bob,=0A> >>>=0A> >>>> Many network engineers typica= lly, though incorrectly, perceive a=0A> >> transmit=0A> >>>> unit as one et= hernet packet. With WiFi it's one Mu transmission=0A> or one=0A> >> Su=0A> = >>>> transmission, with aggregation(s), which is a lot more than one=0A> et= hernet=0A> >>>> packet but it depends on things like MCS, spatial stream po= wers,=0A> Mu=0A> >> peers,=0A> >>>> etc. and is variable. Some data center = designs have optimized the=0A> >>>> forwarding plane for flow completion ti= mes so their equivalent=0A> transmit=0A> >>>> unit is a mouse flow.=0A> >>>= =0A> >>> [SM] Is this driven more by the need to aggregate packets to amort= ize=0A> >> some cost over a larger payload or to reduce the scheduling over= head or=0A> to=0A> >> regularize things (as in fixed size DTUs used in DSL = with G.INP=0A> >> retransmissions)?=0A> >>=0A> >> it's to amortize costs ov= er a larger payload.=0A> >>=0A> >> the gap between transmissions is in ms, = and the transmission header is=0A> >> transmitted at a slow data rate (both= for backwards compatibility with=0A> >> older=0A> >> equipment that doesn'= t know about the higher data rate modulations)=0A> >>=0A> >> For a long tim= e, the transmission header was transmitted at 1Mb (which is=0A> >> still=0A= > >> the default in most equipment), but there is now an option to no longe= r=0A> >> support=0A> >> 802.11b equipment, which raises the header transmis= sion time to 11Mb.=0A> >>=0A> >> These factors are so imbalanced compared t= o the top data rates available=0A> >> that=0A> >> you need to transmit seve= ral MB of data to have actual data use 50% of=0A> the=0A> >> airtime.=0A> >= >=0A> >> David Lang=0A> >>=0A> >=0A> >=0A> ________________________________= _______________=0A> Cake mailing list=0A> Cake@lists.bufferbloat.net=0A> ht= tps://lists.bufferbloat.net/listinfo/cake=0A> ------=_20221019172631000000_33111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

4 microseconds!

=0A=

 

=0A

On Wednesday, Octobe= r 19, 2022 3:23pm, "David Lang via Cake" <cake@lists.bufferbloat.net>= said:

=0A
=0A

> you have to listen and hear nothing for some timeframe before y= ou transmit, that
> listening time is define in the standard. (isn'= t it??)
>
> David Lang
>
> On Wed, 19 Oct= 2022, Bob McMahon wrote:
>
> > I'm not sure where the = gap in milliseconds is coming from. EDCA gaps are
> > mostly dri= ven by probabilities
> > <https://link.springer.com/article/1= 0.1007/s10270-020-00817-2>. If
> > energy detect (ED) indicat= es the medium is available then the gap prior to
> > transmit, a= ssuming no others competing & winning at that moment in time, is
&= gt; > driven by AIFS and the CWMIN - CWMAX back offs which are simple pr= obability
> > distributions. Things change a bit with 802.11ax a= nd trigger frames but the
> > gap is still determined by the bac= koff and should be less than milliseconds
> > per that. Things l= ike NAVs will impact the gap too but that happens when
> > anoth= er is transmitting.
> >
> >
> > [image: im= age.png]
> >
> > Agreed that the PLCP preamble is at = low MCS and the payload can be orders
> > of magnitude greater (= per different QAM encodings and other signal
> > processing tech= niques.)
> >
> > Bob
> >
> > On= Wed, Oct 19, 2022 at 12:09 AM David Lang <david@lang.hm> wrote:
> >
> >> On Tue, 18 Oct 2022, Sebastian Moeller wrote:=
> >>> Hi Bob,
> >>>
> >>&g= t;> Many network engineers typically, though incorrectly, perceive a
> >> transmit
> >>>> unit as one ethernet pa= cket. With WiFi it's one Mu transmission
> or one
> >>= ; Su
> >>>> transmission, with aggregation(s), which is= a lot more than one
> ethernet
> >>>> packet b= ut it depends on things like MCS, spatial stream powers,
> Mu
= > >> peers,
> >>>> etc. and is variable. Some = data center designs have optimized the
> >>>> forwardin= g plane for flow completion times so their equivalent
> transmit> >>>> unit is a mouse flow.
> >>>
= > >>> [SM] Is this driven more by the need to aggregate packets= to amortize
> >> some cost over a larger payload or to reduc= e the scheduling overhead or
> to
> >> regularize thi= ngs (as in fixed size DTUs used in DSL with G.INP
> >> retran= smissions)?
> >>
> >> it's to amortize costs ov= er a larger payload.
> >>
> >> the gap between = transmissions is in ms, and the transmission header is
> >> t= ransmitted at a slow data rate (both for backwards compatibility with
= > >> older
> >> equipment that doesn't know about th= e higher data rate modulations)
> >>
> >> For a= long time, the transmission header was transmitted at 1Mb (which is
&= gt; >> still
> >> the default in most equipment), but t= here is now an option to no longer
> >> support
> >= ;> 802.11b equipment, which raises the header transmission time to 11Mb.=
> >>
> >> These factors are so imbalanced comp= ared to the top data rates available
> >> that
> >= > you need to transmit several MB of data to have actual data use 50% of=
> the
> >> airtime.
> >>
> >= ;> David Lang
> >>
> >
> >
>= _______________________________________________
> Cake mailing lis= t
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.= net/listinfo/cake
>

=0A
 ------=_20221019172631000000_33111--