Subject: Re: DC meeting: Discussion question #1, releaseable resources

From: Jim Bound <[email-masked]>
Date: Wed, 1 Dec 1999 01:51:58 -0500 (EST)

Hi Ralph,

>>This is idempotent and I can see no where we break the multiple server
>>model.  The protocol keeps on ticking whether there is 1...N links and
>>1...N servers.  

>It doesn't break the multiple server model, but (as I interpret the text)
>does not explicitly point out that the client may interact with multiple
>servers.  This might be a good place to add text about how the spec
>allows for concurrent interaction with multiple servers.

I think I may have missed where your going:

Are you going here:

client for le0 on 3ffe::12::12/48 (just one interface):

Client can send Requests to any server that it may have learned of or
about from the multicast solicit?  Thanks...

Nothing in the protocol prohibits this behavior but we don't call it out
either.

>>4.3. DHCP Request Message Format
>>
>>   In order to request configuration parameters from a server, a client
>>   sends a DHCP Request message, and MAY append extensions [15].  If
>>   the client does not know any server address, it MUST first obtain
>>   one by multicasting a DHCP Solicit message (see Section 4.1).
>>
>>Here is where we might add that this solicit in fact will support
>>multiple instants of solicit on different links (subnets in IPv4 terms)
>>or in section 4.1.  
>
>
>OK...

But this is different than my question above here it means:

client at le0 3ffe::12:12/48 sends a solicit on that link and hears
from severs.
client at le1 4ffe::12::12 (different link) sends a solicit on that link
and hears from servers.

Nothing in the protocol prohibits this behavior but we don't call it out
either.

>>5.3. Receiving DHCP Advertise Messages
>>
>>   After a client has received a DHCP Advertise message, it has the
>>   address of a server for subsequent DHCP Request messages.
>>
>>   [...]
>>
>>   Unless a DHCP Advertisement is received with a preference equal
>>   to 255 (see Section 4.2), the client MUST wait CLIENT_ADV_WAIT
>>   seconds after issuing the DHCP Solicit message in order to receive
>>   the Advertisement with the highest preference.  After waiting for
>>   that period of time, a client MUST select the highest preference
>>   server as the target of its DHCP request.  If a client receives an
>>   advertisement with a preference of 255, it does not have to wait for
>>   any more advertisements.
>>
>>Here what we are saying was an addition from the Chicago meeting.
>>
>>We assume the client on the same link could hear from multiple servers
>>as we were told by the working group in Chicago.  Per the working group
>>we added the preference field to the Advertisement message.  The way the
>>code and implementation could work is as follows:
>>
>>  boolean head_cheese_server = FALSE;
>>  int *head_cheese_server_data
>>  pthread_start_client_solicit;  /* this is not how it looks but */
>>  time_interrupt_set (CLIENT_ADV_WAIT);
>>  while (pthread_CLIENT_ADV_WAIT_not_back) {
>>    get_advertisement_message(server_msg_block);
>>    If (server_msg_block->preference_value = 255) {
>>       head_cheese_server = TRUE;
>>       head_cheese_server_data = server_msg_block;
>>       break;
>>    } else 
>>        store_this_server_for_later_sort (server_msg_block);
>>  }
>>  /* not putting in check here for discussion if no advertisements
>>     came back */
>>  If (head_cheese_server)
>>   use_the_head_cheese_server_for_request(server_msg_block);
>>  else
>>   sort_and_pick_highest_preference_server(server_msg_block);
>>
>>But the point is that we listen to multiple servers and select among
>>them based on the preference field from the server unless a server says
>>I am the boss or head cheese use me.  The first server to be heard that
>>does this wins.

>I don't see how this mechanism allows for use of more than one server.

Ok.  I am listening.

>The mechanism explicitly says "pick the one head_cheese or highest
>priority server".  What crieria does the client use to decide to use
>and choose a second server? 

Right now we don't specify that but we could?  If the client keeps the
server responses.  

Do you think we should define a mechanism to select a second, or even
third server?

Off the top of my head I would say I would use the preference ordinal
value?  

>>The client may store all server advs for later use too.
>>
>>   If a client sends a DHCP Request to a highly preferred server but
>>   fails to receive a DHCP reply from that server after following the
>>   retransmission algorithm in section 8, the client MUST then try to
>>   send a DHCP Request to a less preferred server.
>>
>>>(I think this section, at least, needs to be rewritten to allow interaction
>>>with multiple servers.  Under what conditions may a client disregard the
>>>server preference and begin a transaction with a second server with a
>>>[presumably] lower preference?)
>
>>So do you believe we should say the client SHOULD store servers that
>>respond to the solicit and then discuss the case when the client will
>>use a server of lower preference?
>>
>>This I believe resolves your concern and is doable?

>No, this doesn't exactly address my concern.  What I read is a mechanism
>for *serial contact* with multiple servers, but *interaction* with only
>one server at a time; i.e., the client works down the list, one server at a
>time, until it successfully completes a transaction with *one* server.

The protocol selects a server yes.  The criteria we have agreed to thus
far in the WG is to use the preference field to pick that server.
Once the client has done that selection for that interface it is the
server it uses.  For another interface the process begins again.  Each 
associated client interface on a link will spawn a new solicit.

Why would a client want to change servers if its working is what I am
wrestling with?

But if the client's server is not responding it can use a server learned
from the advertisements or from a new solicit.

Why would a client want to speak with one server for one set of
parameters and another server for another set of parameters?  Now we are
getting into SLP space I think.??

But maybe I am missing some data point?                         

thanks
/jim

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Dec 1999 07:41:33 -0500 (EST)

At 10:02 AM 11/30/99 -0500, you wrote:
>>Potentially open issues in the use of multiple servers:
>
>>* Text that implies interaction with a single server through use of
>>singular reference to "server" and through omission of any specific
>>reference to multiple servers
>
>This is pretty clear and pretty easy to fix IMO.

I agree.

>>* Semantics of Solicit message in the presence of multiple DHCP services:
>>how does a client know when it should interact with multiple servers; how
>>does a client differentiate between redundant servers (from the same
>>service) and servers with different resources?
>
>Just sent suggestion to fix that which will support getting this done
>rather expediently in the spec.  

Do you mean the prefix to be associated with a resource?  Or is the prefix
part of the message header?  If the latter is true, then the client will
be able to identify different groups of equivalent servers from which it
has received responses?

How does the client decide which group or groups of servers to contact?
I could imagine popping up a dialog box to the user - "You can connect to
these services - which do you want to connect to?" (where the "services"
are the groups of servers that have offered addresses; I tried to write
the dialog in English rather than talking about "offered addresses").

What is the mapping from a server prefix to some human-readable name?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Dec 1999 07:41:41 -0500 (EST)

At 10:02 AM 11/30/99 -0500, Jim Bound wrote:
>>[...]it may
>>be that we need to clarify that a client needs to send multiple Solicit
>>messages, one to each potential DHCP service, to find the highest
>>preference server from each DHCP service.  
>
>The solicit is a multicast sendmsg() for a link (subnet) then the client
>will hear from multiple servers, which as you pointed out in other mail
>we need to clarify for the multiple server case.

OK, I guess we need to agree on an abstraction for a "DHCP service" and define
a mechanism for identifying services.  Then, we need to fix 5.3 to state
that a client applies the server selection algorithm to each service and
can contact one appropriate server from each service.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Dec 1999 07:41:50 -0500 (EST)

At 12:24 PM 11/30/99 -0500, Thomas Narten wrote:
>I think we are actually in agreement. My use of "does not support"
>appears to have been confusing and misleading. The underlying message
>formats certainly could support a client having multiple
>interactactions with different servers simultaneously.  However, the
>spec itself has little text on this and my expectation of what folks
>would actually implement (based on my read of what the current text
>says should be implemented) is that clients will in practice pick one
>server and interact only with it.

Ah, yes, we are in agreement.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Dec 1999 07:42:01 -0500 (EST)

At 10:46 AM 11/30/99 -0800, you wrote:
>Probably it is better to describe states as pertaining to a
>transaction, than to a client.  Maybe it would be enough to
>specify that any client has to be able to run several state
>independent state machines simultaneously.  Maybe it would
>be even better to specify that state variables should not have
>global process scope.  Thread variables might have to be indexed
>into arrays per thread or something.

I don't think we want to go into those implementation details.
In fact, I don't think a client *has* to implement multiple
state machines for correctness.  I could imagine a single client
thread managing multiple interfaces with an event-driven
implementation.

>On the other hand, I think that many protocols can be specified
>in a way that is simple enough to allow correct implementations
>that don't rely on state machines.

In fact, we never intended to *mandate* a state machine for a
DHCPv4 implementation.  It seemed like a good way to describe the
client's behavior but not (necessarily) an implementation.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 1 Dec 1999 07:40:59 -0500 (EST)

At 10:01 AM 11/30/99 -0500, Jim Bound wrote:
>Mike has proposed to add an address prefix of topological significance
>to the address extension.  The only realeasable resource we have right
>now.  For other reasons but close to the same reason.
>This could be added to also support knowing if a server is within the
>administrative domain as Barr suggested.

Jim, Mike: I can't find the message or messages with this proposal.  I
don't understand what you mean by "an address prefix of topological
significance".  And, would this prefix be part of the server's IPv6
address or a new field in the address extension or ???

>The way this would work is on the Advertisement we would add a field for
>the server to put its prefix topological significance.  When the client
>goes to release a resource to a server the address would be checked
>against that stored value for servers and provide the client knowledge
>if in fact that server can release the address.
>
>This is more doable than using a service bit mask for now and if we in
>the future define other than addresses we can use the server prefix as
>part of that releasable resources associations.  

I read this to explain that the prefix would identify groups of equivalent
servers, and that a client would use the prefix associated with a resource
to identify which of the servers it knows about can accept the released
resource.

How does the client learn about other servers to which it might release
a particular resource?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Dec 1999 09:01:02 -0500 (EST)

> Would you be willing to support my contention that, instead, the
> state machine be associated with the transaction by which the
> IP address is expected to be obtained?  This seems to avoid some
> of the possible negative interaction between independent requests.

Transactions are ephemeral, so I don't see how you can associate state
machines with them.   Am I misunderstanding what you are saying here?
When I said that the xid is used to associate an incoming event with a
state machine, I didn't say that of course the xid changes with each
transaction, so once the state has changed, and incoming
(retransmitted) packet associated with a particular state machine
would no longer be recognized as being associated with that state
machine, and would have to be ignored.   I suppose that given that in
DHCPv6 the server can initiate a transaction, the transaction ID by
itself couldn't be used to associate a given transaction to a given
state machine.

			       _MelloN_

---

From: Thomas Narten <[email-masked]>
Date: Wed, 1 Dec 1999 14:20:05 -0500 (EST)

Charlie,

> Ralph Droms wrote:

> > Put succinctly, I know of no abstract reason to preclude the concurrent
> > interoperation of a DHCP client with multiple servers.  In my opinion, the
> > current spec does not adequately describe the details of concurrent use of
> > multiple servers to ensure interoperable DHCPv6 clients that will provide
> > predictable, manageable, useful behavior.

> I hope you be willing to point out text that is wrong, or suggest
> some strategy for us to forestall erroneous interpretations.

I have been trying (for quite some time) to say that there are parts
of the spec that are unclear or ambiguous. I've also pointed out
specific text. This goes as far back as my 9/98 review.  However, I
sense that you simply disagree and don't see the need for changes. If
my concerns about the overall clarity of the spec were just my own
personal opinion, I'd let it drop. But in speaking with others, I hear
similar concerns and concurrance that the issues I've raised are
valid. Hence, I can't just let them drop. I read your response to
Ralph's specific comments as just saying "no, the spec is fine, there
is no need for changes".  I don't have the cycles to keep circling the
bush on this one.  We are just going to have to agree to disagree on
this point.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 1 Dec 1999 15:17:35 -0500 (EST)

Hello Thomas,

> bush on this one.  We are just going to have to agree to disagree on

Actually, I don't want to be disagreeable at all, and I do not
object to changing the specification to make it clearer.  However,
I don't know exactly what isn't clear, so I cannot myself suggest
the changes.  I reckon that Mike and Jim may have more of an idea
about why the current wording is unclear, and so I will look forward
to suggestions from them or anyone else about how to make the
existing wording clearer.  As long as the intended meaning does
not change, I have only encouragement for the effort.

Regards,
Charlie P.

---

From: Jim Bound <[email-masked]>
Date: Wed, 1 Dec 1999 23:40:06 -0500 (EST)

folks...I am catching up now and reading serially and responding...
got yanked this p.m. 

>address or a new field in the address extension or ???

[If mike has not already sent it].  This is an idea Mike sent around and
was to present at Wash D.C. but we did not get to that bullet.  I will
let Mike resend it was in one of his summaries on resolution.  Mike can
find it quicker than I me thinks :---)...

>to identify which of the servers it knows about can accept the released

Yep.

>How does the client learn about other servers to which it might release

I think thats the absraction we need from the previous mail thread I
just responded too.  We would have to have a means to identify this.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 1 Dec 1999 23:37:26 -0500 (EST)

>be able to identify different groups of equivalent servers from which it

I had mean't the former but now as I read you mail I think your right we
need to do the latter.  OK let me bounce this off Charlie and Mike. And
hope others comment too.  But good suggestion.

>the dialog in English rather than talking about "offered addresses").

That would be friendly for sure.

>What is the mapping from a server prefix to some human-readable name?

Open discussion.  I don't know off the top of my head.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 1 Dec 1999 23:39:55 -0500 (EST)

>can contact one appropriate server from each service.

Yep.  If we do that first the next step I think will be easier too.
Plus if we do this right we should not have to mess with the other
messages they will work idempotently and if they don't we can fix them
but right now I think they do but will check for sure.

So do you have a suggestion on the abstraction?

thanks
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 2 Dec 1999 05:37:59 -0500 (EST)

> How about if we say that a router advertisement with the 'M' bit
> set means that all prefixes advertised in the extensions are for
> managed links?

As far as I can tell that would mean a change to RFC 2462 - which is a draft
standard. Do we really want to change that spec and make it go back to
proposed standard?

If you (and the WG) feels there is a strong need for the routers to
be able to tell the hosts which prefixes the host can/should ask the
dhcp server about, I think it would be better to build that as a backwards
compatible extension to the router advertisement.
But before we go down that path I'd like to be convinced that such
a feature is necessary.

> If a router has some managed links and some unmanaged links,
> then it needs to send out two different router advertisements,
> one for the managed links, and one for the unmanaged links.

Sure, routers already send different router advertisements on different
links since they need to contain different prefixes.

> If more ambitious suggestions were in order, I might suggest
> the creation of an 'M' flag from the reserved flags of the Prefix
> Information option.

That would be one possible way to do this in a backwards compatible way.
But as I said, I don't see the need for this.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 2 Dec 1999 05:38:53 -0500 (EST)

Charlie Perkins wrote:

> A router advertises a prefix, and its willingness to be a default
> router. 

Correct.

> I infer that it wants to be a default router for that
> prefix.

Incorrect. It is a default router for any IPv6 address.

Even though there are about 6000 lines in RFC 2461 you managed to read
something between those lines that has never been the intent. I'm impressed :-)

  Erik

>  I suspect there would be cases where a router would want
> to be a default router for some prefix(es) and not for others.
> This would be especially true for the multihoming case.  In such
> cases, I reckon distinct advertisements would be needed.
> 
> Or maybe I am confused.
> 
> Regards,
> Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 9 Dec 1999 09:15:58 -0500 (EST)

Charles Perkins <[email-masked]> writes:

> 1. I can imagine a _lot_ of releasable resources in the future, but
>    it would be a mistake to try to specify them before we can have
>    DHCPv6 as a Proposed Standard.  After that time, new extensions
>    to specify new releasable resources will come up for discussion
>    in a natural way, as long as we have a natural mechanism specified
>    for handling them.  Some possible examples of releasable
>    resources:

>    = disk space
>    = network memory
>    = I/O devices
>    = Licensed software
>    = time-metered equipment
>    = ports
>    = protocol translators

After thinking about these examples a bit, I am not sure they are
compelling examples of a potential releasable resources. In each of
the above, they are not a resource like addresses are today in sense
that they are given to the client and the client then uses
them. Rather, they seem more like services/servers, in which a special
protocol is needed to actually use the service. For example, to use
remote disk space or remote memory, the client would need to use a
special protocol to access the server. Moreover, the protocol would
likely be specific to the service being provided. Thus, providing the
address of the server would be something that DHCP could do (or,
perhaps even better, SLP should be used to find it), but that's about
it. The client would use the service-specific protocol to actually
access the resource and negotiate with the server about its usage. So
I really don't see how these make sense as a releasable resource.

The licensed software might be an exception, in the sense that perhap
the software could be sent to the client and the client could then use
it for the duration of the lease. But even here, I suspect there would
be much more to providing such a solution than just having a
releasable resource via DHCP. For example, the code would probably be
large enough that  one wouldn't want to use DHCP to actually transfer
it, but that then means we have a special (non-DHCP) protocol and it
becomes unclear what benefit the DHCP portion provides.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 9 Dec 1999 11:41:04 -0500 (EST)

Thomas Narten wrote:

> protocol is needed to actually use the service.

(>> == me)
(>  == Thomas)
I am wholly in favor of using SLP for resolving service needs, and
I picked those examples exactly because I don't think they need SLP.

>                                                For example, to use
> special protocol to access the server.

So, for instance, I would expect that there might be an NFS scratch
space resource extension.  This dependency on protocol is reflected
today in DHCPv4.  Furthermore, it is reflected even in other extensions
for non-releasable resources.  For instance, one asks for an NTP
timeserver, not just a timeserver.  And, one asks for a DNS server,
not just a name directory server.

>                   ......              Thus, providing the
> address of the server would be something that DHCP could do

Yes.

>                                                                 (or,
> perhaps even better, SLP should be used to find it),

Probably not in those cases.

>     The client would use the service-specific protocol to actually

It makes sense for the DHCP server to identify servers for the client,
when the DHCP server has been configured to do so.  It makes sense for
disk space per subnet, network memory per subnet, and I think in every
one of the other cases that I enumerated.

> becomes unclear what benefit the DHCP portion provides

To be clear, I do not say that we have designed the protocols for each
of the other cases.  I also do not say that anyone has designed the
extension.  I only offer them as examples that are somewhat realistic.
Until the details are worked out, it is probably all to easy to find out
things that _might_ be wrong with each of them.

It could also be the case that there would be competing ideas.  Some
people might want to model disk space as a SLP service.  It's an idea
that is worth exploring.  My feeling is that the only service attributes
that matter are location and size of the space requirement, and that is
not so cogent an argument for use for SLP vs. DHCP.  But, other things
might matter - like latency, transfer speed, and so on.  Furthermore,
since I lost the "protocol" argument in SLP, it is a moot point whether
"protocol" would be a service attribute for selection by way of SLP.
Thus, this is not a distinguishing characteristic for determining
whether to use SLP or DHCP.

For the purposes of this discussion, we are only trying to figure out
whether to worry about specifying behavior now for releasable resources.
My vote is to delay the actual layout of a general packet format for
such resources, and just try to make sure that DHCP _could_ support
such things in the future.  I think we are well along the way to making
that happen.

Regards,
Charlie P.