<div dir="ltr">I'm confused.  <a href="https://warpproject.org/trac/wiki/802.11/wlan_exp/app_notes/dcf_with_hidden_nodes" target="_blank">An AP sending a CTS is telling others not to transmit so the AP can listen and successfully decode energy per the RTS originator</a>.  I don't see this a denial of service, though a device blasting CTS might be able to create a DoS attack - not sure.<br><br>Going back to the original question about ED only which I think hit the issues Jonathan pointed out.  <br><ul><li>The software might be simpler, but the hardware would need to be overspecified to the point of making it unreasonably expensive for consumer devices.<br></li><li>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.<br></li><li>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.<br></li></ul><div>Being a software guy, I hope it's ok to ask more "dumb" questions ;) </div><div><ol><li>Why would consumer "hardware" be unreasonably expensive?  Is it a mfg yield thing?  Not possible per the state of CMOS radio process technology?   Just curious to what would drive the expense.<br></li><li>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 when they aren't useful, e.g. ED only would have been sufficient?   Can a device (tx) know the state of the EDCA arbitrations and decide if backoffs are likely to be required or not?</li></ol><div>Again thanks to all for the edifications.</div></div><div><br></div><div>Bob</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 27, 2018 at 9:44 PM Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Aug 27, 2018 at 8:32 PM David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>> wrote:<br>
><br>
> Think of the DoS possibilities if you can tell other networks to not transmit.<br>
<br>
Actually, that's a thing. google for "ap suppression".<br>
<br>
<br>
<br>
<br>
> David Lang<br>
><br>
><br>
> > On Mon, Aug 27, 2018 at 6:56 PM Bob McMahon <<a href="mailto:bob.mcmahon@broadcom.com" target="_blank">bob.mcmahon@broadcom.com</a>> wrote:<br>
> >><br>
> >> 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.<br>
> >><br>
> >> Bob<br>
> >><br>
> >> On Mon, Aug 27, 2018, 6:52 PM David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>> wrote:<br>
> >>><br>
> >>> On Mon, 27 Aug 2018, Bob McMahon wrote:<br>
> >>><br>
> >>>> I thought that RTS/CTS would handle the case of hidden nodes, i.e. a device<br>
> >>>> that fails to successfully transmit can resort to RTS/CTS to get the<br>
> >>>> receiver to reserve time for it.  Also, lack of a RX ack seems ok to<br>
> >>>> trigger MAC level retransmits.<br>
> >>><br>
> >>> the problem isn't getting the receiver to reserve time for it, it's getting the<br>
> >>> other transmitter(s) to not step on it when it transmits. Those other<br>
> >>> transmitters may belong to different people, sharing a channel with your system<br>
> >>> and nothing else.<br>
> >>><br>
> >>> David Lang<br>
> >>><br>
> >>>> It seems the LBT bug is the collision avoidance overheads when it isn't<br>
> >>>> needed, i.e. no other energy would cause the RX PHY to fail its decode and<br>
> >>>> the EDCA backoffs had no benefit, stochastic or otherwise.   Optimizing<br>
> >>>> that out is said to be not possible from local information only and per<br>
> >>>> "shared" spectrum.<br>
> >>>><br>
> >>>> Bob<br>
> >>>><br>
> >>>><br>
> >>>> On Mon, Aug 27, 2018 at 3:33 PM David Lang <<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a>> wrote:<br>
> >>>><br>
> >>>>> On Mon, 27 Aug 2018, Jonathan Morton wrote:<br>
> >>>>><br>
> >>>>>> So in practice, it's easier to measure SNR at the receiver, or<br>
> >>>>> indirectly by<br>
> >>>>>> observing packet loss by dint of missing acknowledgements returned to<br>
> >>>>> the<br>
> >>>>>> transmitter.<br>
> >>>>><br>
> >>>>> Also, there may be other transmitters that the recipient of the packets<br>
> >>>>> can hear<br>
> >>>>> that you cannot hear, so it's not possible to detect colliding<br>
> >>>>> transmissions<br>
> >>>>> directly in all cases.<br>
> >>>>><br>
> >>>>> This is another trap that digital/wired people fall into that doesn't<br>
> >>>>> really<br>
> >>>>> apply in the analog/radio world.<br>
> >>>>><br>
> >>>>> David Lang<br>
> >>>>><br>
> >>>><br>
> >><br>
> >> _______________________________________________<br>
> >> Make-wifi-fast mailing list<br>
> >> <a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferbloat.net</a><br>
> >> <a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
<br>
<br>
<br>
-- <br>
<br>
Dave Täht<br>
CEO, TekLibre, LLC<br>
<a href="http://www.teklibre.com" rel="noreferrer" target="_blank">http://www.teklibre.com</a><br>
Tel: 1-669-226-2619<br>
</blockquote></div>