Subject: RE: IETF58 - Network Status

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Nov 2003 21:46:45 +0200

Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Roland Bless
> Sent: 13 November, 2003 7:08 PM
> To: Randall Gellens
> Cc: [email-masked]; [email-masked]
> Subject: Re: IETF58 - Network Status
> 
> 
> Hi Randall,
> 
> > I have been consistently unable to maintain a connection for more 
> > than a very few minutes, usually not even long enough to 
> establish a 
> > VPN tunnel and fetch one message.  The 802.11 coverage comes and 
> > goes; the APs seem to vanish and I see nothing for a while, 
> > eventually the network comes back but only briefly.  This has been 
> 
> I can partly confirm your observations, since
> I often see my driver reporting a signal strength of 0 for seconds.
> The connection is somehow unstable as my log also reports
> (NSIS meeting this morning, actually not crowded)
> Nov 13 10:41:01  kernel: eth1: New link status: AP In Range (0005)
> Nov 13 10:41:03  kernel: eth1: New link status: AP Changed (0003)
> Nov 13 10:41:25  kernel: eth1: New link status: AP Out of Range (0004)
> Nov 13 10:41:26  kernel: eth1: New link status: AP In Range (0005)
> Nov 13 10:42:58  kernel: eth1: New link status: AP Changed (0003)
> Nov 13 10:45:18  kernel: eth1: New link status: AP Out of Range (0004)
> Nov 13 10:45:18  kernel: eth1: New link status: AP In Range (0005)
> Nov 13 10:45:18  kernel: eth1: New link status: AP Changed (0003)
> Nov 13 10:45:23  kernel: eth1: New link status: AP Out of Range (0004)
> Nov 13 10:45:24  kernel: eth1: New link status: AP In Range (0005)
> Nov 13 10:45:54  kernel: eth1: New link status: AP Changed (0003)
> Nov 13 10:46:28  kernel: eth1: New link status: AP Out of Range (0004)
> Nov 13 10:46:28  kernel: eth1: New link status: AP In Range (0005)
> ... and so on...
> however, it seems also to depend on the cards firmware and driver,
> so other people may have no problems at all...
> Inspite all the problems, it works well enough to get things 
> actually done.
> 
> > the case in every session I've attended, as well as tonight's 
> > plenary.  It doesn't seem to matter if the room is crowded 
> or empty, 
> > or where I sit.
> > 
> > I have attempted to only select the 'ietf58' network, but often the 
> > network vanishes and there are no networks visible; other times the 
> > only visible "network" is an ad-hoc calling itself 'ietf58'.
> 
> I wasn't often successful to reattach to APs after my card was
> "hi-jacked" to ad-hoc cards announcing ietf58. Setting the 
> essid again to the same value seems to do trick, however,
> often I see signals of strength 0 (maybe the card is confused then..).
> Furthermore, it happens often that I don't get an IPv6 address
> directly after activating the card (maybe the RA doesn't get through).
> 
> Cheers,
>  Roland
> 
>

---

From: Brett Thorson <[email-masked]>
Date: Thu, 13 Nov 2003 18:50:11 -0500

On Thursday 13 November 2003 14:46, Romascanu, Dan (Dan) wrote:
> Yes, this looks to affect some models of cards and drivers more than other.
> Unfortunately, I fell this time in the unlucky category. The same model of
> card, driver, and OS that worked perfectly for many in many other similar
> events, including the last three or four IETF meetings made my work
> impossible this whole week with the wireless setting at this IETF network.
> On this respect this was - for me - by far the worst IETF since I am using
> wireless connectivity. Sorry guys.

The only thing thing you have to be sorry for is not coming to us sooner.  If 
you had come to us sooner, we could have been able to solve some of your 
problems or fix it all together.

We hope that by working together to solve these problems we can help you out.  
I have heard many comments from many people that this has been a great 
wireless IETF.  We identified several client problems, and we saw a larger 
number of infected machines.  If the wireless did suffer (which I don't think 
it did because of our volunteer team who worked VERY hard and configuring it) 
it was due to problems simply beyond our control.

And as always, we are happy to take in more volunteers.  If there is something 
you don't like, hop on board and solve the problems!

Cheers, and I hope to hear more from you, in realtime next time these issues 
pop up.

--Brett
> _______________________________________________
> 56crew mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/56crew

---

From: Tim Chown <[email-masked]>
Date: Fri, 14 Nov 2003 00:27:22 +0000

Brett,

It would be great if you could publish all the issues that came up, how
you fixed them, and a brief overview of what you deployed (at the start
and end) for the event.

Tim

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 13 Nov 2003 19:57:33 -0600

--On 13. november 2003 21:46 +0200 "Romascanu, Dan (Dan)" 
<[email-masked]> wrote:

> Yes, this looks to affect some models of cards and drivers more than
> other. Unfortunately, I fell this time in the unlucky category. The same
> model of card, driver, and OS that worked perfectly for many in many
> other similar events, including the last three or four IETF meetings made
> my work impossible this whole week with the wireless setting at this IETF
> network. On this respect this was - for me - by far the worst IETF since
> I am using wireless connectivity. Sorry guys.

not been around long?
I remember one of the earlier Washington IETFs.... a LOT fewer laptops, but 
even bigger problems. And that even without the misbehaviour seen today.

we're living on the bleeding edge, and this time it seems we're bleeding 
more than usual, thanks to some problems we still don't understand fully.

so rather than worrying, let's see what we can do to help....

if someone - for instance - has EFFECTIVE tools for triangulating and 
locating ad-hoc stations, perhaps they can bring them to the next IETF 
meeting?

                     hARALD

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Nov 2003 20:15:43 -0600

basic lessons previously learned were not put to use here, e.g., lowering
the radios so wetware limits range and reduces xmtrs bandwidth fight.

randy

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 13 Nov 2003 20:22:30 -0600

Sitting in the Thursday plenary, I note none of the network-to-ad-hoc 
flappage that have been plaguing us the past few days.

Did the attackers get bored and go home?

Did the accidental ad-hocers finally get their settings right?

Did someone deploy a good blocking mechanism?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 13 Nov 2003 21:33:27 -0500

>the radios so wetware limits range and reduces xmtrs bandwidth fight.

We also had the new overly "helpful" operating systems and a variety of 
infected machines eating bandwidth.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: Andrew Partan <[email-masked]>
Date: Thu, 13 Nov 2003 21:33:30 -0500

> locating ad-hoc stations, perhaps they can bring them to the next IETF 

Another suggestion - it would have been real useful if the software
on my laptop could have been told to ignore some APs (or some other
laptops pretending to be APs), or to only listen to this other set
of APs.  White/black listing of APs...
	--asp

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2003 20:56:01 -0600

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "IMC" == IMC  <Paul> writes:
    IMC> Sitting in the Thursday plenary, I note none of the network-to-ad-hoc 
    IMC> flappage that have been plaguing us the past few days.

    IMC> Did the attackers get bored and go home?

  No, you are just sitting in the wrong part of the room.
  But, it is much better than it was at SAAG.

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: "bill" <[email-masked]>
Date: Thu, 13 Nov 2003 19:06:20 -0800

I would have agreed with you until I just bounced onto the aodv network
- oh well

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Hoffman / IMC
Sent: Thursday, November 13, 2003 6:23 PM
To: [email-masked]; [email-masked]
Subject: RE: IETF58 - Network Status

--Paul Hoffman, Director

---

From: "Theodore Ts'o" <[email-masked]>
Date: Thu, 13 Nov 2003 23:22:25 -0500

> of APs.  White/black listing of APs...

On Linux machines, as root type the command:

iwconfig eth1 ap 00:0C:30:1A:69:A2

To force the access point to be 00:0c:30:1A:69:A2

I don't know if there's a way to make this work for those cards where
the ap selection is done in firmware.

						- Ted

---

From: [email-masked]
Date: Thu, 13 Nov 2003 23:43:03 -0500

> infected machines eating bandwidth.

How depressing.  Does anybody have any good estimate on what % of machines were
infected with one or more of the usual standard-equipment pieces of
bandwidth-sucking malware?

It's sad that at an IETF this is a problem, "preaching to the choir" and all
that.  On the other hand, it's not an IETF-only problem. I was at a SANS class
we were hosting a few months ago on using tcpdump.  So just for grins, I set up
a little tcpdump script, and after about 2 hours, right before the lunch break,
I announced "We have some 280 people in this lecture hall, and so far I've seen
97 MAC addresses on the wireless talking to POP-over-SSL on port 995, and 80 or
so talking cleartext POP".  Some guy in the back of the room asked if I was
grabbing passwords, and I told him "I'm a white hat.  I was gathering *only*
SYN packets for statistical purposes.  I have *no* idea what anybody *else* in
this 100,000 square foot building was grabbing out of the air".

It was pretty easy to identify the 80 or so then... all "deer in headlights"
and tapping at keyboards furiously.. :)

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Nov 2003 22:58:08 -0600

> Right. Like this really works. This just ensures that the folks in the
> middle of the room will get really bad performance. Been there.

the opposite.  it allows us to put xmtrs in the middle of the room
without contending with others.

randy

---

From: Roland Bless <[email-masked]>
Date: Fri, 14 Nov 2003 15:51:34 +0100

On Thu, 13 Nov 2003 23:22:25 -0500

> To force the access point to be 00:0c:30:1A:69:A2

You're lucky that your driver and card support this.
 
> the ap selection is done in firmware.

Unfortunately, the driver for my Lucent card doesn't support this
command and I presume that it's not possible w/ the current firmware. As
someone already stated: though the card was quite good and stable at
past meetings, this time it was really annoying. Either the firmware
needs an update to take the new conditions (mixed environment w/ ad-hoc
nets) into account or I'll have to change the vendor.

Roland

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 14 Nov 2003 11:21:02 -0500

> nets) into account or I'll have to change the vendor.

I strongly recommend the Cisco Aironet 350 cards.  They're a bit more
expensive, but they support "iwlist eth1 scan" (to list all available
access points and their ssid's), as well as forcing the use of a
specific access point via "iwconfig eth1 ap <macaddr>".  They also
have a stronger transmitter (100mW), and a more sensitive receiver, so
they tend to work better in marginal areas (such when you're trying to
sponge off a carelessly left wide-open Linksys router in someone's
apartment in NYC :-).

I generally travel with an old Orinoco (Lucent) card for lending to
people who need cards, and a prism 2 card for special situations
(i.e., airsnort and special driver hacking), but most of the time, I
use the Aironet 350 card as the best, most flexible 802.11b client
adapter that I've found to date.

						- Ted

---

From: shogunx <[email-masked]>
Date: Thu, 13 Nov 2003 11:51:57 -0500 (EST)

> nets) into account or I'll have to change the vendor.

I'm pretty sure its not fireware thats tthe issue.  Make sure your kernel
is patched with the latest version of wireless extensions, then compile
wireless-tools calling includes from the patched kernel headers.

> Roland

sleekfreak pirate broadcast
world tour 2002-3
live from the pirate hideout
http://sleekfreak.ath.cx:81/

---

From: Roland Bless <[email-masked]>
Date: Fri, 14 Nov 2003 18:07:02 +0100

On Thu, 13 Nov 2003 11:51:57 -0500 (EST)

> wireless-tools calling includes from the patched kernel headers.

Though I'm able to do this (which may not be true for other linux users), 
and, it really costs a lot of time to do it. I've done it several times at past 
meetings, because the driver wasn't stable enough and crashed my kernel 
several times. This time I contacted the author of the driver and he had no
idea how to override the firmware's handover decision, sorry.

Roland

---

From: shogunx <[email-masked]>
Date: Thu, 13 Nov 2003 16:39:05 -0500 (EST)

Roland,

> several times.

Which driver/kernel version are you working with?

I have been using a collection of prism2 chipset based card on my
clustered lan, where the parallel processing traffic is significant,
running a hostap and openmosix patched 2.4.20 kernel, and have never had a
problem.

> This time I contacted the author of the driver and he had no
Do you have the code for the firmware, or only a binary?

Scott

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Nov 2003 11:00:39 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Theodore" == Theodore Ts'o <[email-masked]> writes:
    Theodore> On Linux machines, as root type the command:

    Theodore> iwconfig eth1 ap 00:0C:30:1A:69:A2

    Theodore> To force the access point to be 00:0c:30:1A:69:A2

    Theodore> I don't know if there's a way to make this work for those cards
    Theodore> where 
    Theodore> the ap selection is done in firmware.

  It does not work. You get an error.
  And your solution keeps you from roaming to other APs as you move. 
We need 
   1) whitelists and blacklists
   2) a way to authenticate the APs

---

From: Scott Lystig Fritchie <[email-masked]>
Date: Thu, 13 Nov 2003 20:29:00 -0600

>>>>> "rb" == Randy Bush <[email-masked]> writes:

rb> basic lessons previously learned were not put to use here, e.g.,
rb> lowering the radios so wetware limits range and reduces xmtrs
rb> bandwidth fight.

As someone who has only been peripherally aware of the activities of
the NOC Team wireless specialists to implement those "basic lessons"
and the rest of their art, I do not believe this statement is
warranted.  As always, constructive suggestions are appreciated.

-Scott

---

From: Chris Elliott <[email-masked]>
Date: Thu, 13 Nov 2003 21:38:49 -0500 (EST)

Chris.

> randy

Chris Elliott  CCIE# 2013       |         |
Customer Diagnostic Engineer   |||       |||
RTP, NC, USA                  |||||     |||||
919-392-2146              .:|||||||||:|||||||||:.
[email-masked]        c i s c o S y s t e m s

---

From: Franck Martin <[email-masked]>
Date: 18 Nov 2003 09:40:55 +1200

I have been following this thread...

My question, how can we deployed WiFi networks in town for global
roaming with SIP phones when the IETF itself has trouble to deploy it...

Is there something wrong in the WiFi protocol that needs fixing?

Cheers

> middle of the room will get really bad performance. Been there.

----
Franck Martin
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Nov 2003 02:18:50 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Franck" == Franck Martin <[email-masked]> writes:
    Franck> My question, how can we deployed WiFi networks in town for global
    Franck> roaming with SIP phones when the IETF itself has trouble to
    Franck> deploy it...

    Franck> Is there something wrong in the WiFi protocol that needs fixing?

  Yes, despite all of 802.11i, the beacons are not authenticated.

---

From: "Perry E.Metzger" <[email-masked]>
Date: Tue, 18 Nov 2003 09:56:15 -0500

>   Yes, despite all of 802.11i, the beacons are not authenticated.

There are other problems too. The fact that 802.11 tries to be
reliable by doing its own retransmits results in massive congestive
collapse when a protocol like TCP is run over it. The designers did
not read our documents on requirements for link layers. A knob that
allowed you to turn off (or at least tune down) the retransmission on
a network would be very valuable, but I know of no gear that does
that. Also, 11b has a poorly selected set of channels that overlap.

My biggest piece of advice, though, to those setting up such networks
is to deploy monitoring stations in addition to deploying base
stations. That way you'll have some idea of how performance is doing
without needing your users to tell you that there is a problem.

Perry

---

From: Marcus Leech <[email-masked]>
Date: Tue, 18 Nov 2003 10:55:56 -0500

>without needing your users to tell you that there is a problem.
In the presence of ARP spoofing, 802.11i, either with TKIP or CCM will not
provide any guarantees of security.

My advise would be to continue to place your 802.11 networks out in front
of an IPSec gateway.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 18 Nov 2003 17:54:50 +0100

On 18-nov-03, at 15:56, Perry E.Metzger wrote:

> The fact that 802.11 tries to be
> collapse when a protocol like TCP is run over it.

Hardly.  TCP plays nice and slows down when either the RTTs go up or 
there is packet loss (which will happen due to congestion eventually). 
Radio links like this are simply too unreliable to run without 
additional protection: TCP isn't equipped to operate in environments 
with double digit packet loss percentages.

What I saw in some rooms at some times in Minneapolis and also in 
Atlanta is massive packet loss and huge round trip times. This 
indicates there are simply too many people trying to cram too much data 
through the wireless network. This isn't going to work well whichever 
way you slice it.

> Also, 11b has a poorly selected set of channels that overlap.

1. Talk to the FCC.
2. Why do you think there are 11 overlapping channels rather than 3 
non-overlapping channels? Our colleagues at the IEEE aren't stupid.

---

From: "Perry E.Metzger" <[email-masked]>
Date: Tue, 18 Nov 2003 12:08:26 -0500

> there is packet loss (which will happen due to congestion

I would suggest that you have a look at what tcpdump looks like in a
conference room at the IETF. It isn't pretty. I'm kicking myself for
not saving my packet traces -- they would make my point far better for
me than any amount of argumentation in English.

> Radio links like this are simply too unreliable to run
> without additional protection: TCP isn't equipped to operate in
> environments with double digit packet loss percentages.

A protocol that had been tuned for use with TCP would have been fine
-- heavy FEC and some moderate retransmissions in case of corruption
or station handoffs are okay. The problem is not when you try to be
reliable in the face of radio interference, but when you also try to
be reliable in the face of congestion -- which is precisely what the
system does. Storing huge queues of packets when there is congestion
does no one any favors. TCP needs packet drops and fairly low standard
deviations on packet delays to do its job well, and 802.11 does
precisely the wrong thing.

Perry

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Nov 2003 02:53:35 +0900

Perry;

>>environments with double digit packet loss percentages.

I agree with you, Iljitsch.

> precisely the wrong thing.

But, Ethernet does (or did, when it was CSMA) the same thing and
RFC1958 says:

   To quote from [Saltzer], "The function in question can completely and
   correctly be implemented only with the knowledge and help of the
   application standing at the endpoints of the communication system.
   Therefore, providing that questioned function as a feature of the
   communication system itself is not possible. (Sometimes an incomplete
   version of the function provided by the communication system may be
   useful as a performance enhancement.")

Because of exponential backoff, aggregated bandwidth of multiple TCP
over congested WLAN should not be so bad.

However, RED like approach to attempt retries only a few times may be
a good strategy to improve latency.

							Masataka Ohta

---

From: "Perry E.Metzger" <[email-masked]>
Date: Wed, 19 Nov 2003 11:45:25 -0500

> a good strategy to improve latency.

A RED approach would be good, but in general there has to be a limit
on the queue. Your wireless interface should not become a packet long
term storage facility. I've seen RTTs to the base stations on the
order of 25000ms (that's 25 SECONDS) or more. If you can't deliver a
packet a through 300ns distance of air in 10ms, it is probably time to
drop it.

Perry

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 20 Nov 2003 04:38:18 +0900

Perry;

> term storage facility.

We are saying the same thing.

> I've seen RTTs to the base stations on the

With exponential back-off with base 2, 10ms of initial delay
becomes 40s after 12 attempts of retry.

Note that 25000ms of delay does not necessarily mean that a station
has a large buffer.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 19 Nov 2003 22:12:59 +0100

> A RED approach would be good,

15 authors of RFC 2309 can't be wrong.  :-)

> but in general there has to be a limit

I think there is some middle ground between 25000 and 10 ms. While the 
former is definitely too long, the latter is probably too short. 
(Ignoring the fact that base stations may need to buffer packets for 
much longer than this when clients are in power save mode.) But the 
problem with sharing the airwaves is that you can't be sure how long 
it's going to take to deliver packets. The difference between first try 
@ 11 Mbps and having to retry several times @ 1 Mbps can easily be a 
factor 40. Last but not least, any system sitting between a high 
bandwidth link (100 Mbps ether) and a low bandwidth link (802.11b) 
needs to buffer to accommodate for the bursty nature of IP. Usually a 
round trip time worth of buffer memory is recommended. So that would be 
around 300 ms worth of 6 Mbps (= net throughput at 11 Mbps) = 220 
kilobyte.

---

From: "Perry E.Metzger" <[email-masked]>
Date: Wed, 19 Nov 2003 17:16:21 -0500

Iljitsch van Beijnum <[email-masked]> writes:
> I think there is some middle ground between 25000 and 10 ms.

10ms is the middle ground. That's enough for a bunch of retransmits on
modern hardware. Coupled with aggressive FEC, that's more than enough
time.

> But the problem with sharing the airwaves is that you can't be
> sure how long it's going to take to deliver packets.

Actually, the speed of light is remarkably deterministic. If the
network is so loaded that you can't send a packet in that period, you
should drop so that all the TCPs back off.

> The difference between first try @ 11 Mbps and having to retry
> several times @ 1 Mbps can easily be a factor 40.

None the less, it ends up being much lower by orders of magnitude than
what the standards currently permit.

The packet dumps I got from the 802.11b networks during the worst
periods at IETF revealed what you would readily expect -- that TCP
collapses badly when the underlying network does something very dumb.

By the way, it would also be a good idea if the standard did proper
power control of the mobile stations.

-- 
Perry E. Metzger		[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Nov 2003 00:26:57 +0100

> modern hardware.

Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 
byte packet already takes 12 ms, without any link layer overhead, 
acks/naks or retransmits. End-to-end retransmits take even longer 
because of speed of light delays.,

> Coupled with aggressive FEC, that's more than enough time.

FEC sucks because it also eats away at usable bandwidth when there are 
no errors.

> Actually, the speed of light is remarkably deterministic.

Yes, but unfortunately, bit errors aren't.

> If the

Absolutely not. This leads to constant packet loss because of minor 
bursts, which TCP reacts very badly to. Try setting the output queues 
of your friendly neighborhood router to something extremely low and 
you'll see what I mean.

> collapses badly when the underlying network does something very dumb.

So let's:

1. Make sure access points don't have to contend with each other for 
airtime on the same channel
2. Make sure access points transmit with enough power to be heard over 
clients associated with other access points
3. Refrain from using too much bandwidth
4. Make use of higher-bandwidth wireless standards such as 802.11g

> power control of the mobile stations.

Why? Raising the power output of the stuff you want to hear over these 
clients is much, much simpler.

Also, all of this makes it sound like the network was very bad in 
Minneapolis. That isn't my experience: I usually had good bandwidth, 
with the exception of just a couple of sessions, and I ended up 
associated with an ad-hoc network only a few times.

By the way, I did some testing today and the results both agree with 
and contradict conventional wisdom with regard to 802.11 channel 
utilization. When two sets of systems communicating over 802.11b/g are 
close together, they'll start interfering when the channels are 3 apart 
(ie, 5 and 8), slowing down data transfer significantly. This indicates 
that in the US only three channels can be used close together, but four 
in Europe: 1, 5, 9, 13. However, with the two sets of stations are NOT 
close together (but still well within range), such as with a wall in 
between them, 3 channels apart doesn't lead to statistically 
significant slowdowns, and even 2 channels apart is doable: 25% 
slowdown at 802.11b and 50% slowdown at 802.11g. So that would easily 
give us four usable channels in the US (1, 4, 8, 11) and 5 in Europe 
(1, 4, 7, 10, 13), or even six / seven (all odd channels) in a pinch. 
(As always, your milage may vary. These results were obtained with 
spare hardware lying around my house.)

---

From: "Perry E.Metzger" <[email-masked]>
Date: Wed, 19 Nov 2003 18:49:06 -0500

Iljitsch van Beijnum <[email-masked]> writes:
> acks/naks or retransmits.

Most of us are not running at that speed on 802.11b. Obviously if
you're running at a lower speed adjustments should be made.

> End-to-end retransmits take even longer because of speed of light delays.,

We're talking about to the base stations only. End to end is not the
issue. The issue is 802.11 tries to be reliable to the base station,
with disastrous results.

> FEC sucks because it also eats away at usable bandwidth when there
> are no errors.

Having TCP collapse sucks too, because then no one can use the
network. In any case, one can adjust the the armor to cope with the
average bullet density. If the S/N is clean, you don't need as much
FEC.

>> If the network is so loaded that you can't send a packet in that
>> period, you should drop so that all the TCPs back off.
>
> Absolutely not.

Well, then, I'm sorry that you don't understand what happens to TCP
under these circumstances, but some of the rest of us do. I was seeing
packet traces showing clear signs of congestive collapse on the radio
networks, and most of it was created by the packet warehousing our
lovely 802.11 hardware believes it should do to "help" with the packet
loss problems.

It all reminded me horribly of the sorts of packet traces one saw on
ARPANET and NYSERNET before VJ flow control became the norm. I really
regret not saving packet traces. If I had known some people didn't
understand congestion control I wouldn't thrown them away. Luckily,
there is always the next conference.

Perry

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 20 Nov 2003 09:45:05 +0900

Iljitsch;

> Retransmits on what type of hardware? At 1 Mbps transmitting a 1500 byte 
> packet already takes 12 ms, without any link layer overhead, acks/naks 
> or retransmits. End-to-end retransmits take even longer because of speed 
> of light delays.,

That is a improper calculation.

The requirement from TCP is that, on lightly loaded link,
probability of packet drop should be very small.

For example, if probability of collision is (despite CSMA/CA) 0.1,
2 retries will be enough to make packet drop probability 0.1%.

If there are hidden terminals, probability of interference will
get worse that more retry will be desired.

And, with exponential back-off, delay will be doubled as the
number of retries in increased by 1.

> FEC sucks because it also eats away at usable bandwidth when there are 

Wrong reason.

FEC is fine against thermal noise.

However, FEC does not work at all here, because, with a collision,
contents of colliding packets will be lost almost entirely.
 
> 4. Make use of higher-bandwidth wireless standards such as 802.11g

No.

2 should be:

	Make sure clients and access points transmit with equal power
	to be heard over each other to enable CSMA/CA collision
	avoidance with random delay

1 is a performance improvement but is not a serious problem if
CSMA/CA is working well.

3 is not specific to wireless and is irrelevant.

4 helps little but is not very meaningful as PPS, rather than BPS,
is becoming the limiting factor, especially for applications with
small packets such as VOIP.

> clients is much, much simpler.

It is a good idea for some wireless protocol.

However, it is the worst thing to do against CSMA/CA.

Others won't notice your presence and won't reduce transmission rate.
 
> By the way, I did some testing today and the results both agree with and 
> contradict conventional wisdom with regard to 802.11 channel 
> between them, 3 channels apart doesn't lead to statistically significant 
> slowdowns, and even 2 channels apart is doable: 25% slowdown at 802.11b 
> and 50% slowdown at 802.11g. So that would easily give us four usable 
> channels in the US (1, 4, 8, 11) and 5 in Europe (1, 4, 7, 10, 13), or 
> even six / seven (all odd channels) in a pinch. (As always, your milage 
> may vary. These results were obtained with spare hardware lying around 
> my house.)

The results, it seems to me, completely agree with the conventional
wisdom.

						Masataka Ohta