[e2e] Expected latency for a single hop: What about 802.11networks?

[crk@research.att.com]

QoS for 802.11 was actually fairly recently defined in the 802.11e
specifications.  Since the scheduled "HCCA" mode is a new addition, it
is true that it's not widely deployed, but that will change.

The unscheduled QoS mode uses randomized backoff timers with the max
value determined by traffic class; the scheduled HCCA mode allows
clients to provide a Tspec to an Access Point, which can then provide
bounded and predictable delay.  Since HCCA "parameterizes" QoS via
scheduled "polls", the latency is normally max'd at the superframe
beacon interval, but can be less.  A typical example is 20 msec in one
implementation that we've worked on with several vendors.  These kinds
of guarantees will be needed if you ever want to use 802.11 to provide
WVoIP in an enterprise environment...

I believe we have some good model outputs from simulations that we could
share if there is an interest...

Regards,
chuck

-----Original Message-----
From: end2end-interest-bounces at postel.org
[mailto:end2end-interest-bounces at postel.org] On Behalf Of David P. Reed
Sent: Monday, August 08, 2005 1:31 PM
To: Detlef Bosau
Cc: Michael.kochte at gmx.net; end2end-interest at postel.org
Subject: Re: [e2e] Expected latency for a single hop: What about
802.11networks?


The MAC protocol in 802.11 is not ALOHA.  You'd best get the spec if you

really want to understand it, because it's pretty complex.

It doesn't detect collisions, however.  Nor does it depend on positive 
acks.  It relies on collision avoidance techniques to reduce collision 
losses to a low enough level, and end-to-end acks to clean up the rest.

There is a "polled" mode (point coordination function) that is hardly 
ever implemented.   Instead, the "distributed coordination function" 
(DCF) is typically employed, but modified in many cases by RTS/CTS 
exchanges, this latter being the means to reduce collisions in most 
cases (CTS is a positive ack for RTS).

Many networks are set up so that CTS/RTS applies only to long frames 
(i.e. file transfers).

Ultimately, it means that what TCP/ACK observation sees when an 802.11 
link is involved depends on how well the CTS/RTS works.