Re: IETF62 Network and Terminal Room Information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Caveat: I am not an RF engineer. I am no longer trusted to do much network
	config by my team. I run NetBSD rather than a commercial OS and can
	probably be regarded as a (l)user.

We're a mix of platforms, probably more diverse than most smaller, dense
deployments. Few of us get to CeBIT or other situations likely to be like
this, for worst-case networking. You can't compare this to the density
problem of normal offices.

I'm not convinced the RF sharing in the A/B/G world works well with older
cards, and I am sure we have some people who are using pre-'gold' lucent
chipsets locked at 2mbit. 

I saw a lot of non-printable SSID. I saw a lot of non-IETF, non-hotel SSID.
Some I think are in the area, some were undoubtedly the ad-hoc nonsense
which crops up. 

I got better WiFi in the Irish Pub.

I am not sure the range of SSID helped. the WEP ssid probably shouldn't be
even remotely close to 'ietf62' and having ietf62-wep didn't help me all
the time (this is classic 'problem between chair and keyboard' stuff)

We have people who freak their power budget. I don't think this is in the
wider community interest. 

We have people who run two cards at once. They probably get a good outcome
but I wonder if it helps everyone around them to have two cards
cataleptically bouncing between the same channel

We have people on laptops with bad engineering. some laptops with built-in
WiFi have truly awful issues with large pods of water and fat moving
between them and the base-station, some appear to prefer being in specific
orientation.

I was routinely seeing 8+ base stations on 2 channels. I've said this to
people in the NOC, and not yet been contradicted but isn't it meant to be a
bad idea to have that many base stations visible on the same channel? I
thought even spread spectrum had limits to how much RF you could use with
other people.

The reports that turning off one of A or G improved things makes me think
this has a lot to do with the link layer, the RF.

the DHCP service was odd. If the net is not actually congested, then why
would a DHCP server take so long to serve? I don't see why the beast was
stuck in backoff land for so long. Of course, if it too was seeing
melt-down of the carrier, the ARP must have been lost along with all the
good bits, but when the net was palpably 'up' -Why does a DHCP server
struggle? If its not scaling for a large flat net, should we be walking
back to smaller partitions, or to some other address discovery service
which does scale to large flat nets?

Not all Mac users had a good time. This is often a clue that things are bad
in the infrastructure. I don't have one, and they love to tell me how
perfect it was for them on their MacOS, but they just weren't doing it, and
I think that also says there was something wrong out there on the aether.

I respect the effort the NOC put in. I know its hard to do this stuff, I do
it writ small on far smaller conferences, and I know how hard it can be to
make it fly when the users are grumpy. But we're not going to get to a
better place without recognizing this was NOT a good network, even
relatively speaking inside the history of IETF nets.

-George

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]