[ietf78-tech] EDUroam connect request

[Chris Elliott]

On Jul 8, 2010, at 4:00 PM, Geert Jan de Groot <geertj at psg.com> wrote:

> On Thu, 08 Jul 2010 09:56:42 -0700 joel jaeggli wrote:
>> Right and that's yet another beacon frame at roughly 100ms intervals on 
>> both a and b channels times ~60 aps with two radio's each, I'm all for 
>> having the number of ssids that we need in total to support the client 
>> and role segmentation necessary to run the network, but not more than 
>> that. we already know that a number of devices have finite number of 
>> slots either in their devices drivers or firmware for the number of 
>> beacons they're prepared to cache before ejecting some.
> 
>> From Jim's notes, we'll have 4 SSID's: 
> - ietf-portal
> - ietf-portal-a
> - ietf.1x
> - ietf-a.1x
> 
> If the admission control fails, we'll add:
> - ietf
> - ietf-a
> for a total of 6 concurrent SSID's in operation.
> 
> This learns me 2 things:
> 1. We hope we can run with 6 SSIDs (or we have a problem with our
>   backup scheme in case the admission thing fails)

The fixed limitation is that these AP's have 8 MAC addresses per radio. So they support 8 broadcast SSID's per radio.

Now, we could broadcast certain SSID's on some AP's and others on another set of AP's, but that is a real administration headache, not to mention likely to cause spotty coverage for some users.

We often have one or more experiments that require additional SSID's, and we are likely to want to have the v6only SSID (not sure if you call that an experiment at this point or not).

So we are very likely to come very close or hit 8 SSID's on the 5Ghz radios.

The management SSID should not be broadcast, so it won't be an issue here.

> 2. We should have a way to change the SSID config of our AP's
>   automagically, as we might need to add ietf and ietf-a
> 
> Perhaps we can let eduroam use the 5th slot? If 5 slots turns out
> to be a problem, then we can decide to take it down, but if we do,
> we also know that our backup plan for the admission experiment
> is faulty.
> 
> I suspect Paul would not mind that if the number SSID slots would 
> turn out to be an issue, and removing eduroam would fix that issue, 
> the answer would be to remove eduroam.
> (and, at the same time, pray we don't need to implement our
> backup plan).

This is true for all experiments. They get turned off first if either they appear to be causing a problem or the resources they are consuming are needed for core networking functionality.

> You guys have much more experience - would this be workable?

I have some of the same concerns as Joel about the amount of beacons, both from the bandwidth consumed, necessarily at the lowest speed configured, and because of the behavior of some clients.

Fortunately, we tend to keep the lowest speed configured at 5.5 or 11Mhz for .11b. This helps the area most affected and the clients most likely to have more primitive algorithms.

So, I think this is doable as a separate SSID, but we can't take on many additional experiments that require their own broadcast SSID. We will need to monitor the network and pay attention to any reported problems that may be caused or aggravated by this amount of broadcast SSID's.

Chris.

> Geert Jan
> 
> (jim - fixing my email setup now - sorry!)
> 
> _______________________________________________
> ietf78-tech mailing list
> ietf78-tech at daedelus.com
> http://www.daedelus.com/mailman/listinfo/ietf78-tech