Subject: Re: [manet] transmission failure info from 802.11 cards

From: Erik Nordström <[email-masked]>
Date: Thu, 01 Apr 2004 10:20:10 +0200

On Mon, 2004-03-29 at 19:42, David Young wrote:
> On Sun, Mar 28, 2004 at 02:16:05PM -0500, Vinayak Naik wrote:
> > 
> > I have a quick question about an ad-hoc network that we are trying
> > to build with 802.11 cards.
> > 
> > In simulators (such as ns-2), a transmission failure at the MAC layer
> > results in a callback to the routing layer to try for an alternate route.
> > However, with real 802.11 cards in a testbed, is it possible to get
> > a feedback about failure of MAC layer delivery?
> > 
> > Are there any special 802.11 cards that might have this feature?
> 
> Virtually every 802.11 card provides feedback.  Lucent & Prism cards
> will indicate a transmit failure after the retry count has expired.
> The 802.11 ASICs by Atheros, ADMtek, and Realtek will tell you how many
> times they re-tried a transmission. The hardware capability is there,
> however, the Tx-failure indications do not climb the networking stack
> to routing daemons.
> 

Are these counters and TX-failure indications actually accessible in
drivers or are they implemented in firmware? Do you have any pointers to
anyone that has managed to use this in actual routing protocol
implementations?

Erik

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Sukanta K. Hazra" <[email-masked]>
Date: Thu, 01 Apr 2004 18:06:40 +0800

----- Original Message -----
From: "Erik Nordstr?m <[email-masked]>"
Date: Thu, 01 Apr, 2004 16:20 SGT
Subject: Re: [manet] transmission failure info from 802.11 cards

> anyone that has managed to use this in actual routing protocol

In Cisco Aironet card, the linux driver provides the stats. The
stats are exported to the proc filesystem. For a list of stats check the
airo.c driver in the Linux Pcmcia package. As an example below is the 
truncated result of

cat /proc/driver/aironet/eth1/Stats

-----------------
HostTxMc: 0
HostTxBc: 70
HostTxUc: 2266
HostTxFail: 2
HostRxMc: 5608
HostRxBc: 34794
HostRxUc: 1730
HostRxDiscard: 0
SsidMismatch: 17389
ApMismatch: 0
RatesMismatch: 0
AuthReject: 0
AuthTimeout: 0
AssocReject: 0
AssocTimeout: 0
RxMan: 0
TxMan: 0
RxRefresh: 0
TxRefresh: 0
RxPoll: 0
TxPoll: 0
HostRetries: 81
---------------

- Sukanta

---

From: Christian Tschudin <[email-masked]>
Date: Thu, 1 Apr 2004 14:15:11 +0200 (MET DST)

The problem is with checking the counters on a per-packet basis,
the /proc/driver/aironet interface is too coarse. At least this
indicates that the data would be available. Next thing to know
whether you need to poll the card or not.

  And it's also with the queueing inside the kernel i.e., to associate
failed and successful transmissions with single packets still sitting
somewhere in a buffer. Needs explicit signaling too.

christian.

---

From: l s <[email-masked]>
Date: Thu, 1 Apr 2004 15:06:05 +0100 (BST)

I have a question regarding the radio interference
between nodes which are not in direct contact at the
data-link (MAC) layer when using IEEE 802.11 MAC &
PHY.

802.11 does use CSMA, meaning it listens to the radio
channel being clear enough before transmitting?

If I have a simple setup as follows where the links
are
MAC links:

   #0 --- #1 --- #2 --- #3 --- #4 --- #5

Where their physical locations could be anywhere as
long as these links are as such.

Then if #1 wants to unicast to #2, and achived a
chance
to commence transmission (ie no carrier sense gave the
go-ahead) then it would:
  #0# -- #1# -- #2# -- #3# -- #4# -- #5#
   g     RTS     - 
   |      -     CTS     g
   |     DAT     -      |
   |      -     ACK     |

'g' indicates the getting of a NAV.
#0 would backoff on hearing the NAV in the RTS from #1
#3 would backoff on hearing the NAV in the CTS from #2

But I am unsure of how the carrier sense works, and
what levels trigger it.
The way I understand it is that a node's backoff
countdown only stops for the duration set in a NAV
rx'd
from another node.
The carrier sense is only used when countdown is at
zero and it is about to transmit?

If this is so, does that mean that #3 may tx whilst #1
is still tx'ing its RTS?

#4 on the other hand is out of data-link range of #2
and so will never hear any NAV from #2 or further, but
it will probably still be in radio interference range.
What I'd like to know is what is the chance that
whilst
#2 is tx'ing (CTS or ACK), will #4 sense a carrier and
thus not tx.
Furthermore, if #4 does not sense the channel busy
(carrier sense) and goes ahead and unicast to #5,
RTS.. .DATA..., then what is the probability of
corruption of
data arriving at #2.

I understand that this likely depends on the coding
scheme being used, the exact physical distances and
the
environment in which it sits, but what I am looking
for
is confirmation my thinking is correct, and some work
that has been done on this.
Some empirical values of this kind of interference
under different circumstances would be nice.

I am looking at this in relation to Admission Control
and Resource Reservation, more accurately in passing a
greater variety of information at the MAC to indicate
network conditions.

Any input would be greatly appreciated.

cheers,
   Lee Speakman
   CCSR, UniS (Uni of Surrey), UK
   http://www.ee.surrey.ac.uk/CCSR/

___________________________________________________________
WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards  www.yahoo.co.uk/internetcafes

---

From: "Sukanta K. Hazra" <[email-masked]>
Date: Thu, 01 Apr 2004 22:54:21 +0800

----- Original Message -----
From: "Christian Tschudin <[email-masked]>"
Date: Thu, 01 Apr, 2004 22:26 SGT
Subject: Re: [manet] transmission failure info from 802.11 cards

> > From: "Christian Tschudin <[email-masked]>"
> > Date: Thu, 01 Apr, 2004 20:15 SGT
> > The airo_start_xmit function in the airo driver returns SUCCESS or
> > ERROR, that can give an indication whether the transmission was
> > successful or not. You could modify the appropriate functions in the
> > kernel code to make use of that indication.
> >
> > At the least, what this proves is that its possible to get indication
> > from the card regarding success or failure of transmission. You can
> > proceed from there, to incorporate it in the routing protocol.
> 
> not really. I browsed through the code only quickly, but it seems clear
> that airo_start_xmit() only tells you whether the driver could QUEUE the
> packet or not. Whether the packet was actually sent or not, you will not
> learn from that. Nor do you know when to look again at the counter
> for detecting the packet's fate. It's an asynchronous world down there.
> 
> christian.

You are right. Thanks for pointing that out.

- Sukanta

> > --
> > Sukanta K. Hazra (Mr.)	<[email-masked]>
> > Institute for Infocomm Research
> > Tel: +65 6874-1953 Fax: +65 6776-8109
> > Homepage: http://www1.i2r.a-star.edu.sg/~sukanta/
> >
> >

-- 
Sukanta K. Hazra (Mr.)	<[email-masked]>
Institute for Infocomm Research
Tel: +65 6874-1953 Fax: +65 6776-8109
Homepage: http://www1.i2r.a-star.edu.sg/~sukanta/

---

From: "Sukanta K. Hazra" <[email-masked]>
Date: Thu, 01 Apr 2004 22:03:13 +0800

----- Original Message -----
From: "Christian Tschudin <[email-masked]>"
Date: Thu, 01 Apr, 2004 20:15 SGT
Subject: Re: [manet] transmission failure info from 802.11 cards

- Sukanta

---

From: Christian Tschudin <[email-masked]>
Date: Thu, 1 Apr 2004 16:26:03 +0200 (MET DST)

christian.

---

From: David Young <[email-masked]>
Date: Thu, 1 Apr 2004 15:49:30 -0600

> for detecting the packet's fate. It's an asynchronous world down there.

The Aironet firmware is capable of indicating transmit success or failure
for each packet using an interrupt. It is possible with Lucent/Prism
firmware for the driver to apply a label to each packet, so that it can
be recognized when the interrupt comes. It *appears* that it is the same
for Aironet.

It is clear that virtually all 802.11 devices can indicate transmit
success/failure for individual packets. It's not clear what the API
will look like, even in the abstract, that the different layers of the
protocol stack will use to get individual success/failure indications.

Dave

-- 
David Young             OJC Technologies
[email-masked]      Urbana, IL * (217) 278-3933