Subject: RE: [dhcwg] Order of occurence of DHCPv6 options

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sat, 15 Jun 2002 12:36:01 -0500

Vijay:

On the order of options, we chose specifically NOT to specify this. There really is no
requirement or overwhelming reason to do this. Putting some options earlier than others
improves performance in some situations so it will be wise for clients (and servers) to
do this, but it is difficult to specify this and a client and server MUST assume the 
worst anyway.

For example, I'd argue that putting the Server Identifier option first (or very early)
is best since it allows all servers that receive this (except for the intended one) to
drop the packet almost immediately. Rather than having to look through 4 options, won't
it be better if these servers only had to look at 1 option (the first).

Though, having said that there is no reason to require this and depending on how a client
or server processes packets, the above might not even apply (for example, if a client or
server always decodes all options to validate the packet, it won't save anything).

So, we specifically decided not to specify option ordering and I think that is a wise
decision. 

Regarding the other issues, some clean-up for the draft will be required to remove and
fix items based on the final status codes/option usage.

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:[email-masked]]
Sent: Saturday, June 15, 2002 1:31 PM
To: [email-masked]
Subject: [dhcwg] Order of occurence of DHCPv6 options

I think, we need to fix the order of options occuring in DHCPv6 messages
for better processing of the messages.

1. Elapsed Time option - Since based on this value only, the relay/server is
going to decide the policy of reply.

2. Status Code - In the case of Failure, this message can be directly
ignored

3. Authentication option - If authentication fails, nothing is needed to
be processed.

4. server-id - If the server id doesn't match, server can ignore it.

5. client-id - If the client id doesn't match, client can ignore it.

6. Rapid commit - Based on this, the server can determine whether it need
to send Advertise or Reply.

If any of these options are occuring, then they MUST occur in this order.

----------------------------------------------------------------------------
--

ConfNoMatch and AddrUnavail are nowhere used. It can be removed.

AuthFailed is also nowhere used. We need to add text saying if the
server/client is not able to authenticate the other, then they
should send reply with error code AuthFailed set.

----------------------------------------------------------------------------
--
R-forw.    *                        *     *      *      *
R-repl.    *                        *     *      *      *

Why Authentication, User class, Vendor class, Vendor specific options
are needed in Relay-fwd and Relay-reply message.

~Vijay

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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Mon, 17 Jun 2002 15:49:18 +0530

Hi Bernie,

The requirement here is PERFORMANCE. Assume there are 1000 requests passing
through a server which are NOT intended to be handled by this server. This
will happen since most of the messages are Multicast only. This is not the
corner case situation as you said, this will happen in most of the cases.
There is nothing wrong in mandating this. This is something like specifying
these options in a fixed mesg header. The server/client will ignore the
remaining
option field, if there is any error in the mesg header.

All of the above, the relay should be lightweight, if the admin has
configured
the relay to load balance based on Elapsed time option and how bad the
performance will be if the relay has to search for this option by parsing
the whole message.

> the above might not even apply (for example, if a client or

Then, this is a poor implementation. If the first option itself is
erraneous, (for ex. auth itself fails), then there is no need to
parse remaining stuff. We should leave these kind of implementation
as corner case and go on mandating options' order of occurence.

~ Vijay

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Saturday, June 15, 2002 11:06 PM
To: [email-masked]'; [email-masked]
Subject: RE: [dhcwg] Order of occurence of DHCPv6 options

Vijay:
On the order of options, we chose specifically NOT to specify this. There
really is no
requirement or overwhelming reason to do this. Putting some options earlier
than others
improves performance in some situations so it will be wise for clients (and
servers) to
do this, but it is difficult to specify this and a client and server MUST
assume the
worst anyway.
For example, I'd argue that putting the Server Identifier option first (or
very early)
is best since it allows all servers that receive this (except for the
intended one) to
drop the packet almost immediately. Rather than having to look through 4
options, won't
it be better if these servers only had to look at 1 option (the first).
Though, having said that there is no reason to require this and depending on
how a client
or server processes packets, the above might not even apply (for example, if
a client or
server always decodes all options to validate the packet, it won't save
anything).
So, we specifically decided not to specify option ordering and I think that
is a wise
decision.

Regarding the other issues, some clean-up for the draft will be required to
remove and
fix items based on the final status codes/option usage.
- Bernie

---

From: Ralph Droms <[email-masked]>
Date: Mon, 17 Jun 2002 08:58:47 -0400

Unitl we have more experience with real implementations, it's hard to know 
exactly what to optimize.  So, let's run some experiments once we have 
interopable implementations and get some experience with real deployments 
so we can understand where the performance hits and improvement 
opportunities are.  Then we can write up that experience and a 
specification for option ordering...

- Ralph

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Mon, 17 Jun 2002 19:32:11 +0530

Ralph,

For something like this, we dont need implementations at all.
Its very sure that there willl be performance degradation
in relay, if the Elapsed time option is not the first one.
If the relay is configured to do load balance, then the relay has to
process the whole message in search of this option, leading to the
performance degradation in relay. we suppose relay to be light weight.
Similar case is for server, if the authentication or server-id is not
first, then it is going to process the whole message to discard the
packet.

This is something like, rejecting the dhcpv6 packet, if
1 <= message type <= 13 is not true. If there are more important
options defined later, which has to occur first, then in
that specification, we can rearrage the order and precedence.
I think, we can define the order of the known important options now.

~ Vijay
-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, June 17, 2002 6:29 PM
To: [email-masked]
Cc: 'Bernie Volz (EUD)'; [email-masked]
Subject: RE: [dhcwg] Order of occurence of DHCPv6 options

- Ralph

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 17 Jun 2002 08:32:03 -0600 (MDT)

> From: "Vijayabhaskar A K" <[email-masked]>

> For something like this, we dont need implementations at all.

Almost no optimization tactic, and certainly including this one,
can be discussed except in the context of a model implementation

> in relay, if the Elapsed time option is not the first one.

That is also wrong.  The packets are not that big and hard to parse
that any except the slowest CPUs with the least nearby memory will
any trouble merely parsing to reject even the IPv6 DHCP packets.

> performance degradation in relay. we suppose relay to be light weight.

You must put a number on "lightweight" before you can talk about it.

How many CPU cycles do you need to parse a packet?  Surely you don't
need more than 3 or 4 CPU cycles per byte of packet.  If your CPU runs
at only 10 MHz, how many packets could you parse and reject?  Do you 
really expect to need to reject that many?

Will the time spent parsing and rejecting a packet in your extremely
slow CPU be more than the time required to deal deal with leaks through
your multicast filter?  Since you're talking about something extremely
slow and lightweight, have you spent the money for perfect multicast
filtering?

> first, then it is going to process the whole message to discard the

That assumes that the server will not parse the entire packet before
deciding what it likes about it.  That is an implementation model.

> I think, we can define the order of the known important options now.

The number of premature optimizations for any protocol or program
may not be unbounded, but it is a very large number.

Vernon Schryver    [email-masked]

---

From: Mark Stapp <[email-masked]>
Date: Mon, 17 Jun 2002 10:34:32 -0400

It is certainly possible that different vendors will choose to make 
different decisions about how to parse and process dhcp options. That does 
not compromise interoperability or protocol robustness. It's reasonable to 
expect that the spec might include some discussion about option ordering, 
as an aid to implementors. But even that belongs in a 'discussion' or 
'notes to implementors' section, not in the core specification. Other than 
that sort of discussion, this is not something that belongs in the spec at 
all. As Ralph notes, once we have deployment experience some clever person 
can volunteer to write the bcp on option-parsing.

-- Mark