Subject: Measurements at IETF65.

From: Andrea G Forte <[email-masked]>
Date: Mon, 28 Aug 2006 18:34:24 -0400

Dear all,

as some of you may know, we have conducted some wireless measurements at 
the 65th IETF in Dallas. Based on previous feedback, we were looking for 
some anomalies in the wireless network. In our measurements we found 
different behaviors for different wireless card vendors.
This is the link to the paper is:
http://www1.cs.columbia.edu/~andreaf/downloads/ietf_measures.pdf

Regards,
-Andrea

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

---

From: Andrea G Forte <[email-masked]>
Date: Mon, 28 Aug 2006 20:18:26 -0400

Joel,

thank you for your comments and for clarifying how the APs were 
deployed. On the Apple clients issue I generally agree with you. We 
considered the Apple behavior good relative to the highly congested 
environment encountered at the IETF meeting. In this particular 
environment most handoffs were triggered by packet loss rather than 
signal strength. The packet loss was caused by congestion which meant 
that moving to a different AP, especially if on the same channel, would 
not help at all. We are looking more closely to how Apple performs 
handoffs and if it has some sort of smart handoff algorithm. Regardless, 
performing too many handoffs is bad in any environment.

-Andrea

Joel Jaeggli wrote:
> Greetings,
>
> That makes for an interesting read especially the client hand-off
> measurement.
>
> just two observations...
>
> The low dis/re-association rate associated with the apple clients is
> described as "good", and in the sense that it reduces churn I agree with
> that. But if in fact it means you continue to remain associated with an
> ap when another is available which is more viable, the user may
> experience poor performance.
>
> With regard to observations about the site. There were two sets of cisco
> ap's deployed, the hotel's were remotely managed by an offsite contrator
> (we had snmp read access and that's it), the others were managed by the
> noc staff using cisco wlse and other tools. Because the hotel's ap's
> were all configured for channel 6 (a questionable practice I agree) our
> map coloring problem was greatly simplified (if you saw a ch6 ap you
> knew whose it was). Each of the chantilly ballrooms had 4 hotel ap's in
> the ceiling, additional hotel ap's were in they foyer and in the
> boardrooms immediately upstairs. Two additional ap's (of our's) were
> located in chantilly west during the thursday plenary that were not
> present on wenesday, one located in the center of the south half of the
> room and one located in the center of the north half, signal from these
> ap's should have been highly attenuated during the meeting as they were
> located under chairs. these ap's were deployed due to the high number of
> associations with ap's at the north end of the room despite our efforts
> at attenuation.
>
> an example can be seen here:
>
> http://www.flickr.com/photos/64986983@N00/148888492/
>
> Overall the existing hotel ap's were both a liability (hard to manage)
> and a serious asset in that they covered the lobby and the attrium's in
>  a building that was approximately 550 meters in length. having them
> reduced the ap count that we had to come up with by order of 40-60 ap's
> and  meant that ap's were already deployed in some fairly hard to reach
> places.
>
>
> Andrea G Forte wrote:
>   
>> Dear all,
>>

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 28 Aug 2006 16:43:17 -0700

Greetings,

just two observations...

-- 
------------------------------------------------------------------------
Joel Jaeggli             Unix Consulting              [email-masked]
GPG Key Fingerprint:   5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2