--On Saturday, 12 March, 2005 12:36 -0600 Baker Fred <fred@xxxxxxxxx> wrote: >... > Something that could come out of this discussion that would be > constructive and helpful might be a set of guidelines for > hosts with respect to the network. I wonder if we could focus > the thread in that direction? I agree that focus would be useful. But another issue, and maybe part of that one, is that we may need a stronger "if it ain't broke don't fix it" attitude toward all of this. I understand that we had some "buyout resulting in unexpected change of vendor" problems this time. No one can avoid those and certainly no one associated with the terminal room operation can be blamed for them. But we have run larger IETF meetings, with presumably as many or more wireless users, in that hotel, and not had nearly the problems of this week. The "same hotel" property indicates that we should not be having surprises with building structure or layout either. More generally, what most of us do when we are trying to troubleshoot something that used to work better than it does now is to ask "what changed" and hope we don't get a really complex answer to that question. This leads me to slightly different conclusions than Fred reaches, with the understanding that I'm theorizing too, and doing so with very little knowledge: * if we could run a pure and open 802.11b network without real problems a year and two years ago, maybe we should let the IEEE experiment with running a mixed 802.11a/b/c environment with and without WEP and with and without 802.11x and we should skip it. Our experience with Internet protocols at higher layers of the stack is that having lots of options for ways of doing something, intermixed in the same environment, often gets to be just too much to cope with under load... even if it works well in smaller-scale lab tests and ought to work in theory. I'm not saying the mixed cases should not work, just that we don't need the added debugging excitement of having developers fly in (much as I appreciate their being willing to do that). The complex cases and interactions are IEEE 802's dogfood; we don't need to eat it for them. * if we need some of the more advanced features, let's pick one feature set and switch to it. That would be inconvenient, but we have done it before and it worked for us. I'm presumably not the only one who ended up with a souvenir FH (rather than DS) card to work at a meeting or two: it is now in the box next to my token ring adapter: I don't think either is likely to get a lot of future use, but so it goes. If 802.11g and 802.11x are the right way to go, let's just do it... even though, with a Centrino-equipped machine, I've learned to rather enjoy not carrying cards around. >... > Another issue may have been (Fred in theory mode again) with > the DHCP service. I saw a number of cases where folks had > trouble getting an address, or their address was changed a few > moments after it came up, or they got one only to have it go > away and not be replaced. That suggests that somehow the > address assignment policy or the server software executing it > had some problems. I observed this too, along with spontaneous disconnects that could not be attributed to the wireless setup (along with many that could). Now DHCP _is_ our dogfood and, if we can't find implementations that work in a satisfactory way under heavy load, I have to hope that someone is wondering about where the protocols or their specifications might be weaker than they should be. But, again, since that basically worked a year or more ago, we may also need to ask whether we are "modernizing" more than is desirable in the sort of production/ support environments that the wireless now represents for IETF. > The best bet, I think, would be for the IETF 62 team to put > together a note (not to this list, but among the appropriate > group) detailing the issues and making recommendations for > future meetings. Concur. john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf