From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8E4103CB35 for ; Tue, 28 Aug 2018 01:43:54 -0400 (EDT) Received: by mail-ed1-x533.google.com with SMTP id k14-v6so423751edr.13 for ; Mon, 27 Aug 2018 22:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ucHkZZ0dJZNe4mRhfW5bNOSHpT5EMDix4pfzPnI1CHs=; b=S4sNn1lu4PdBAVcPE+tTTwYPuiHNU+/VEwWW6ocLDY2lKnZi1Hwl+c1iMXd+/gIFrF FyH8+f+R3kIaafHNpceZ+pvqviEA9XrgEpaRAJBYzxLOBOJscENX1OBgQrijqvAdqrbI 6y8xPWy90XlD5TXXnGFJYFE0P8J05WfEwuiEY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ucHkZZ0dJZNe4mRhfW5bNOSHpT5EMDix4pfzPnI1CHs=; b=oWUlrl+5qfwQJRl8LjDhleRNcXlSv2QwT5XEfuPKUVKyo4M/U7XMeGvyeSoFRqRrbT wmtBfvxstEleojVX+zQfTrk3+PxUCbbfSuZG9HqxhIAsBZJo9dsEZOaebxsCfP9MkBPG T+Dib5NGB4tryFXf9UI6vgnKpyjrgN7g1rRBfhwI+bgAua3WoOyqQmmwTxJptU56L3NC dT4eLu2EBSS0GWkpzCXD9wONKsZUyCU1bHAuuqZC7oS+wIHeBOEwrT2DPQ+YaBpDiYQk CzovWmkNxg+8bTomI7gyaQUi2TvVDOeQL/CApfJiPaBeJx4gjnr/Irrar8htd6i5JdFe 9MrA== X-Gm-Message-State: APzg51CAOTSI+3TmGkqojT6AvuuNB2ajCNNbDVyIUOilP/Qzm8oQh+g7 +QpfftFU3mfsyXaEqGUtYU2xjYB7bvmLOa5Ib5Uf+w== X-Google-Smtp-Source: ANB0Vdan58m9XTuSbIVsXfZgIo2c/eZEelTmIHKPBzIeBvM8lDfcpOn6StDwHilTveQt8kcTfFciyrvUVtG/SEoGZcg= X-Received: by 2002:a50:bec2:: with SMTP id e2-v6mr598913edk.104.1535435033368; Mon, 27 Aug 2018 22:43:53 -0700 (PDT) MIME-Version: 1.0 References: <1535286372.35121837@apps.rackspace.com> <2282D31E-CBEF-4B42-A6A6-4D6394EE0DF7@gmail.com> In-Reply-To: From: Bob McMahon Date: Mon, 27 Aug 2018 22:43:42 -0700 Message-ID: To: Dave Taht Cc: David Lang , Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000bd7fcb0574785311" Subject: Re: [Make-wifi-fast] deep wifi 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: Tue, 28 Aug 2018 05:43:54 -0000 --000000000000bd7fcb0574785311 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm confused. An AP sending a CTS is telling others not to transmit so the AP can listen and successfully decode energy per the RTS originator . I don't see this a denial of service, though a device blasting CTS might be able to create a DoS attack - not sure. Going back to the original question about ED only which I think hit the issues Jonathan pointed out. - The software might be simpler, but the hardware would need to be overspecified to the point of making it unreasonably expensive for consu= mer devices. - Radio hardware generally has a significant TX/RX turnaround time, required for the RX deafening circuits to disengage. Without those deafening circuits, the receivers would be damaged by the comparatively vast TX power in the antenna. - So in practice, it's easier to measure SNR at the receiver, or indirectly by observing packet loss by dint of missing acknowledgements returned to the transmitter. Being a software guy, I hope it's ok to ask more "dumb" questions ;) 1. Why would consumer "hardware" be unreasonably expensive? Is it a mfg yield thing? Not possible per the state of CMOS radio process technolog= y? Just curious to what would drive the expense. 2. Maybe indirect detection via packet loss is good enough - not sure. But still can't get rid of first try transmit's EDCA back offs even if w= hen they aren't useful, e.g. ED only would have been sufficient? Can a dev= ice (tx) know the state of the EDCA arbitrations and decide if backoffs are likely to be required or not? Again thanks to all for the edifications. Bob On Mon, Aug 27, 2018 at 9:44 PM Dave Taht wrote: > On Mon, Aug 27, 2018 at 8:32 PM David Lang wrote: > > > > Think of the DoS possibilities if you can tell other networks to not > transmit. > > Actually, that's a thing. google for "ap suppression". > > > > > > David Lang > > > > > > > On Mon, Aug 27, 2018 at 6:56 PM Bob McMahon > wrote: > > >> > > >> Hmm, not sure I understand the distinction. CTS per the AP informs > those other transmitters to stay quiet per the CTS NAV. I may be > misunderstanding things. Thanks for the continued discussions. It helps > to better thoroughly understand the issues. > > >> > > >> Bob > > >> > > >> On Mon, Aug 27, 2018, 6:52 PM David Lang wrote: > > >>> > > >>> On Mon, 27 Aug 2018, Bob McMahon wrote: > > >>> > > >>>> I thought that RTS/CTS would handle the case of hidden nodes, i.e. > a device > > >>>> that fails to successfully transmit can resort to RTS/CTS to get t= he > > >>>> receiver to reserve time for it. Also, lack of a RX ack seems ok = to > > >>>> trigger MAC level retransmits. > > >>> > > >>> the problem isn't getting the receiver to reserve time for it, it's > getting the > > >>> other transmitter(s) to not step on it when it transmits. Those oth= er > > >>> transmitters may belong to different people, sharing a channel with > your system > > >>> and nothing else. > > >>> > > >>> David Lang > > >>> > > >>>> It seems the LBT bug is the collision avoidance overheads when it > isn't > > >>>> needed, i.e. no other energy would cause the RX PHY to fail its > decode and > > >>>> the EDCA backoffs had no benefit, stochastic or otherwise. > Optimizing > > >>>> that out is said to be not possible from local information only an= d > per > > >>>> "shared" spectrum. > > >>>> > > >>>> Bob > > >>>> > > >>>> > > >>>> On Mon, Aug 27, 2018 at 3:33 PM David Lang wrote: > > >>>> > > >>>>> On Mon, 27 Aug 2018, Jonathan Morton wrote: > > >>>>> > > >>>>>> So in practice, it's easier to measure SNR at the receiver, or > > >>>>> indirectly by > > >>>>>> observing packet loss by dint of missing acknowledgements > returned to > > >>>>> the > > >>>>>> transmitter. > > >>>>> > > >>>>> Also, there may be other transmitters that the recipient of the > packets > > >>>>> can hear > > >>>>> that you cannot hear, so it's not possible to detect colliding > > >>>>> transmissions > > >>>>> directly in all cases. > > >>>>> > > >>>>> This is another trap that digital/wired people fall into that > doesn't > > >>>>> really > > >>>>> apply in the analog/radio world. > > >>>>> > > >>>>> David Lang > > >>>>> > > >>>> > > >> > > >> _______________________________________________ > > >> Make-wifi-fast mailing list > > >> Make-wifi-fast@lists.bufferbloat.net > > >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > > > > > > > > > > > > > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > --000000000000bd7fcb0574785311 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm confused.=C2=A0 An AP sending a CTS is telling others not to transmit so the AP can list= en and successfully decode energy per the RTS originator.=C2=A0 I don&#= 39;t see this a denial of service, though a device blasting CTS might be ab= le to create a DoS attack - not sure.

Going back to the original que= stion about ED only which I think hit the issues Jonathan pointed out.=C2= =A0=C2=A0
  • The software might be simpler, but the hardware would = need to be overspecified to the point of making it unreasonably expensive f= or consumer devices.
  • Radio hardware generally has a significant= TX/RX turnaround time, required for the RX deafening circuits to disengage= .=C2=A0 Without those deafening circuits, the receivers would be damaged by= the comparatively vast TX power in the antenna.
  • So in practice= , it's easier to measure SNR at the receiver, or indirectly by observin= g packet loss by dint of missing acknowledgements returned to the transmitt= er.
Being a software guy, I hope it's ok to ask more = "dumb" questions ;)=C2=A0
  1. Why would consumer &q= uot;hardware" be unreasonably expensive?=C2=A0 Is it a mfg yield thing= ?=C2=A0 Not possible per the state of CMOS radio process technology?=C2=A0 = =C2=A0Just curious to what would drive the expense.
  2. Maybe indir= ect detection via packet loss is good enough - not sure.=C2=A0 But still ca= n't get rid of first try transmit's EDCA back offs even if when the= y aren't useful, e.g. ED only would have been sufficient?=C2=A0 =C2=A0C= an a device (tx) know the state of the EDCA arbitrations and decide if back= offs are likely to be required or not?
Again thanks to all fo= r the edifications.

Bob

On Mon, Aug 27, 2018 at 9:44 PM Dave= Taht <dave.tah= t@gmail.com> wrote:
On Mon, = Aug 27, 2018 at 8:32 PM David Lang <david@lang.hm> wrote:
>
> Think of the DoS possibilities if you can tell other networks to not t= ransmit.

Actually, that's a thing. google for "ap suppression".




> David Lang
>
>
> > On Mon, Aug 27, 2018 at 6:56 PM Bob McMahon <bob.mcmahon@broadcom.com&g= t; wrote:
> >>
> >> Hmm, not sure I understand the distinction.=C2=A0 =C2=A0CTS p= er the AP informs those other transmitters to stay quiet per the CTS NAV.= =C2=A0 I may be misunderstanding things.=C2=A0 Thanks for the continued dis= cussions.=C2=A0 It helps to better thoroughly understand the issues.
> >>
> >> Bob
> >>
> >> On Mon, Aug 27, 2018, 6:52 PM David Lang <david@lang.hm> wrote:
> >>>
> >>> On Mon, 27 Aug 2018, Bob McMahon wrote:
> >>>
> >>>> I thought that RTS/CTS would handle the case of hidde= n nodes, i.e. a device
> >>>> that fails to successfully transmit can resort to RTS= /CTS to get the
> >>>> receiver to reserve time for it.=C2=A0 Also, lack of = a RX ack seems ok to
> >>>> trigger MAC level retransmits.
> >>>
> >>> the problem isn't getting the receiver to reserve tim= e for it, it's getting the
> >>> other transmitter(s) to not step on it when it transmits.= Those other
> >>> transmitters may belong to different people, sharing a ch= annel with your system
> >>> and nothing else.
> >>>
> >>> David Lang
> >>>
> >>>> It seems the LBT bug is the collision avoidance overh= eads when it isn't
> >>>> needed, i.e. no other energy would cause the RX PHY t= o fail its decode and
> >>>> the EDCA backoffs had no benefit, stochastic or other= wise.=C2=A0 =C2=A0Optimizing
> >>>> that out is said to be not possible from local inform= ation only and per
> >>>> "shared" spectrum.
> >>>>
> >>>> Bob
> >>>>
> >>>>
> >>>> On Mon, Aug 27, 2018 at 3:33 PM David Lang <david@lang.hm> wrote: > >>>>
> >>>>> On Mon, 27 Aug 2018, Jonathan Morton wrote:
> >>>>>
> >>>>>> So in practice, it's easier to measure SN= R at the receiver, or
> >>>>> indirectly by
> >>>>>> observing packet loss by dint of missing ackn= owledgements returned to
> >>>>> the
> >>>>>> transmitter.
> >>>>>
> >>>>> Also, there may be other transmitters that the re= cipient of the packets
> >>>>> can hear
> >>>>> that you cannot hear, so it's not possible to= detect colliding
> >>>>> transmissions
> >>>>> directly in all cases.
> >>>>>
> >>>>> This is another trap that digital/wired people fa= ll into that doesn't
> >>>>> really
> >>>>> apply in the analog/radio world.
> >>>>>
> >>>>> David Lang
> >>>>>
> >>>>
> >>
> >> _______________________________________________
> >> Make-wifi-fast mailing list
> >> Make-wifi-fast@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/lis= tinfo/make-wifi-fast
> >
> >
> >
> >



--

Dave T=C3=A4ht
CEO, TekLibre, LLC
ht= tp://www.teklibre.com
Tel: 1-669-226-2619
--000000000000bd7fcb0574785311--