[Berlin-wireless] Tempo Tempo

[Marco Tidow]

moin,

bislang zum thema handfeste details nur hier gelesen: "High Rate Ultra Wideband PHY and MAC Standard"
  ECMA-368.pdf
    http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-368.pdf

dort:
  RTS/CTS handshake
    PCA TXOP related
    in PCF Teil des "network allocation vector (NAV)"
      network allocation vector (NAV)
        indicator
          maintained by each device capable of using PCA
          of time periods when PCAbased transmission onto the wireless medium will not be initiated by the device
            whether or not the device's clear-channel assessment function senses that the wireless medium is busy


ansonsten, probiert ;-)

keine lust auf roman, deshalb stichwort stil:


korrekt:

  overhead bei kleiner node zahl ist gering (Sven-Ola)

  RTS/CTS funktioniert in "reinen" setups wie gewünscht (Rolf)


aber:

  RTS requests können von zwei nodes, die sich nicht hören, auch gleichzeitig gesendet werden
    node dazwischen kriegt dann von keiner der beiden eine RTS-anforderung mit (RTS-collision)
      ==> beide außen-nodes gehen in den exponential-backoff, weil die zwischen-station kein CTS bringt
        ==> "mein" freifunk-wifi "hält die klappe", ggfs. "sehr lang"

und aber:

  über-proportionaler einbruch, wen non-RTS/CTS nets auf demselben channel unterwegs sind
    RTS/CTS frames
      sind selbst von packet-loss oder "moderneren" short-CW WME-wifi-nodes betroffen
      beziehen sich *nur* auf eigene BSSID, sind "cell-local"
        andere nets kümmern sich "einen scheiß" um die RTS "meiner" cell,
          senden einfach ihre payload - und machen durchsatz, "besetzen" die luft ;-)

        keine "abstimmung" über basic "clear channel assessment" hinaus
        zwischen unterschiedlichen cells (BSSID´s)

    weil

      bei ausbleiben des CTS (CTS timeout)
        setzt der exponentiale backoff-mechanismus (CW : contention-window) ein
          ==> "mein" freifunk-wifi "hält die klappe", ggfs. "sehr lang"

und aber:

  OLSR/batmensch trifft fehl-entscheidung wg. der nicht dem realem unicast-szenario entsprechenden ETX´s

    RTS/CTS not used w/ broadcasts ==> zusätzliche asymmetrie zw. unicast/broadcast
      RTS/CTS nur zwischen stationen, "keine anfrage @all"

    selbst bei identischer (fixer) unicast und broad-/multi-cast bitrate



auch interessant:

  RTS/CTS kostet zusätzliche zeit ==> größere link-latency auch bei "freiem" channel

  handshake-anteil steigt mit steigender payload-bitrate über-portional, wenn standard bitrate-automatik aktiv
    "management frames" werden nur mit basic-rate versand

  unklar, wie RTS/CTS in bursting-modes verwendet wird
    verschiedene *ACK varianten, "Duration field" problem
      +TACK
      +B-ACK
      +No-ACK

    best-case:  complex, costly

    worst-case: implementierungs-bugs  :-(
      dann letztlich sowieso nur basic CSMA/CA in funktion

    problem:
      [this-special-used-variant-of-]bursting-in-compatible nodes
      laufen ggfs. beim "erwarten" des CTS in timeout ==> CW-backoff

  implementierung in karten-firmware undurchsichtig, für ad-hoc erst recht
    z.b.
      RTS/CTS "auto-enable" als fallback, trotz user-config RTS "off" (prism2)
        s. thread auf [hostap] in den letzten wochen


alternativ:

  verzicht auf RTS/CTS
      reduziert "clear channel assessment" auf basic CSMA/CA
        basic CSMA/CA
          kollisions erkennung
            basiert auf
              "mit-hören" was andere nodes ankündigen
                - "Duration field" : pseudo-CS(carrier-sense)
              bei übertragungs-versuchen "im nachherein"
                - (ausbleibenden) TACKs
            kein physikalisches CD(collision-detect) *während* des sendens bei wifi möglich
          nimmt collisions in kauf

  dann besser:
    minderung des collision-overhead durch kleine FRAG´s
      kein großer impact (~ 10 %) wenn channel frei, aber im worst-case "geht noch was"


thema heikel, weil:

default-setup der FFF für die meistens leute "die bibel"  : "grüne kreuze als heils-versprechen"

  wie sich wifi-user auch sonst schon nicht trauen, den default-manufacturer channel ("11") zu "verstellen"

  oder freifunker, die  *einfach*  auf dem standpunkt stehen

    wenn die FFF nicht "out-of-the-box" läuft, geht´s eben "überhaupt" nicht
      bestenfalls HF-setup flaky...

    wenn ich keine "sonder-drösel" mache, gerate ich auch nicht in die kritik


funktioniert das default-setup in bestimmten "gegenden" nicht, war´s das für freifunk dort :-(

RTS/CTS hat charakter eines negativen "traffic-shapings"
  wer zufällig von einem non-RTS/CTS nachbar-netz betroffen ist, verliert übermäßig connect zu freifunk-nodes



marco