[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dhcwg] comments on draft-ietf-dhc-dna-ipv4-04.txt
Ted,
Couldn't quite tell from this whether you agreed with me that the text in
the draft was ... too general.
Like your wife, I've occasionally had 802.11 troubles, and I'd be
interested in providing some guidelines that would make it easier for an
802.11 client to deal with those troubles better. I don't read INIT-REBOOT
to mean 'throw out your configuration.' I've read it as 'try to confirm
that your configuration is still valid'; there are lots of ways of
optimizing the confirmation process. The dna draft proposes optimizing it
by avoiding it - skipping the confirmation message based on some heuristic.
The heuristic that's in the text isn't restricted to 802.11 clients, and
isn't time-based or damped. The draft also doesn't discuss interactions
between L2 (which notices that the link has gone down and been
reconnected), the IP stack, and the DHCP client, and I agree with you that
users are most likely to notice a transient link problem if it takes down
their TCP connections.
I'd like to distinguish 'reconfiguration' from 'confirmation'. I agree that
helping 802.11 clients avoid unnecessary reconfiguration is desirable, and
I'd support text that made specific recommendations for those clients. But
the -04 draft loses the benefits of confirmation in too many situations.
-- Mark
At 11:43 PM 11/11/2003 -0600, Ted Lemon wrote:
Some people have made a lot of what I would consider a misreading of
RFC2131 - that INIT-REBOOT is optional. I believe it's optional because
some hosts may not have stable store, not because hosts that *do* have
stable store should ever skip INIT-REBOOT.
I think that in order to get good behavior in the case where we have
flapping going on on an 802.11 link, it's going to require a compromise on
one of three directions. The choices are (remember, this is just for 802.11):
- Try to do it right. This means that when we see a change, we look for
a new configuration but don't immediately throw out the old, in the sense
that we keep the old address configured alongside the new, and only kill
it off after a timeout has passed. I don't think that anybody is going
to implement this, and I'm not seriously proposing it - just wanted to
mention it.
- Compromise in the direction of switching quickly. This means that when
we detect a possible change in attachment, we assume that the old
connection is gone and never coming back. So we throw it away
immediately and switch. MacOS X does this now. My wife Andrea was
unable to get her email for quite a while this afternoon as a result,
because she has a Titanium, which has, shall we say, antenna issues.
She kept losing her access point in the middle of downloading her email,
so she got the same ten messages quite a few times before she gave up.
- Compromise in the direction of switching slowly. AFAIK nobody does this
now. What this means is that when we notice a network transition, we
keep it in mind, but don't try to reconfigure immediately - we wait 90
seconds, long enough for any active TCP sessions to time out. If, during
that timeout period, the old network comes back, we continue using
it. After this period has passed, we give up and move to the new network.
This is a point solution for 802.11. I think that aggressive switching
probably works fine for ethernet and similar media, because a change in
media is usually a physical process. The solutions proposed in DNAv4
having to do with not trying to reconfigure until we actually detect a new
link, as opposed to the loss of the old link, make a lot of sense - this
means that if the switch is power cycled, we don't lose our address, but
if we're plugged into a different switch, we get a new address quickly.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg