--On Saturday, 12 March, 2005 12:36 -0600 Baker Fred
<fred(_at_)cisco(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf