Subject: [dhcwg] comments on draft-ietf-dhc-dna-ipv4-04.txt

From: Mark Stapp <[email-masked]>
Date: Tue, 11 Nov 2003 17:48:50 -0600

I have some comments on draft-ietf-dhc-dna-ipv4-04.txt - on section 2.1 in 
particular.

[2.1] Reachability Test

     Doesn't this sentence in 2.1 sort of turn DHCP on its head?

       "The purpose of the reachability test is to determine whether
        the host is connected to a network on which it had previously
        obtained a still valid routable IPv4 address."

     As I understand it, it's only the DHCP server who knows
     authoritatively whether the address binding that the client
     remembers is still valid. Working around that authority in
     circumstances where the server has failed, if the client could
     actually determine that, would be one thing. But working around
     that without the client's even attempting to confirm its binding
     with the server is problematic.

     This section states that a host may skip confirmation of its DHCP
     address when it reconnects under some circumstances. The DHCP
     INIT-REBOOT state is actually pretty important, and skipping it
     could have some undesireable consequences. As 2.1 is worded now, a
     host could have a week-old memory of an address it got on network
     A, and could re-use it upon reconnecting to network A without
     attempting INIT-REBOOT. That's a pretty dramatic change, if I've
     read the text accurately, and I'm not comfortable with it.

     Is the goal of 2.1 to assist clients who have marginal connections
     - wireless clients whose associations are flapping, for example?
     Maybe a time-based, stateful heuristic would be appropriate
     here. For example, if the host believes that it has reconnected to
     network A, and that it last communicated with the DHCP server on
     network A within the last - one minute? five minutes?  - then it
     could proceed without INIT-REBOOT. If the host had

	  a) been off of network A for more than five minutes, or

	  b) been attached to some other network since it last
	     attached to network A

     then it would go through INIT-REBOOT normally.

     Or are there folks who think that the client should always do
     INIT-REBOOT if it can? In that case, if there's a latency issue
     for some types of client or some types of link, maybe we should
     try to make a low-latency answer available from the server without
     changing the client behavior at all.

Thanks,
Mark

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Nov 2003 23:43:24 -0600

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.

---

From: Mark Stapp <[email-masked]>
Date: Wed, 12 Nov 2003 10:13:00 -0600

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:
>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.
>
>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 
>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.
>
>