RE: [dhcwg] dhcpv6-24: Elapsed Time option

["Vijayabhaskar A K" <[e-mail]>]

RE: [dhcwg] dhcpv6-24: Elapsed Time option
  I feel that this elapsed_time field can be better used by Relays.
  We should not restrict the relays not to use it.

  Request, Renew, Release, Decline - These messages are
  expected to be replied by the particular server which has assigned
parameters, which is
  identified by server id field. So there is no need for the relay to
  divert to secondary server.

  In the case of Solicit and Information-request, the relay can use this
  option to decide up on sending it to secondary server or in load
balancing.

  The problem that Ted referred if the elapsed_time is sent in request wont
be there
  now, since client wont be using the elapsed_time in the request message...

  The possible scenario is...

  Client (SOLICIT (elapsed_time = 0)) --> Relay --> Set A of Servers

  No reply recevied                    <--
                  ..........
                  ..........
  Client (SOLICIT (elapsed_time = 100)) --> Relay --> Set B of servers.

  Case a) -> 1 or more reply received....

  client chooses one of the servers in the set and send REQUEST message

  case b)->no reply received till REQ_MAX_RC
  it can try with less prefered servers in set B who have replied. If still
no reply received...

  it can proceed with solicit. the time elapsed will be the tolal time from
the original SOLICIT sent....
  Client (SOLICIT (elapsed_time = 300)) --> Relay --> Set C of servers

  Its purely configuration issue that whether Sets A B and C are independent
(or)
  one is subset of other one, depending up on whether the relay is trying to
do
  load balancing or trying to take care of failover.

  For confirm and rebind message, A should be subset of B, B in turn subset
of C.
  Because, the client may have got IAs from more than one server and any of
those servers
  should not be left out in subsequent sets.Again, this is purely
configuration issue.

  And processing of elapsed time cannot be a big overhead to the relay. If
the Elapsed_Time
  is used as last option in the client message, the processing will be
easier.

  ~Vijay



  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On Behalf Of
Bernie Volz (EUD)
  Sent: Thursday, May 09, 2002 11:05 PM
  To: 'Ted Lemon'
  Cc: 'Thomas Narten'; '[e-mail]'
  Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option


  Oh, I should add that in -24 we have:

  ---

  22.9. Elapsed Time

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      OPTION_ELAPSED_TIME      |           option-len          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          elapsed-time         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        option-code   OPTION_ELAPSED_TIME (8)

        option-len    2.

        elapsed-time  The amount of time since the client began its
                      current DHCP transaction.  This time is expressed in
                      hundredths of a second (10^-2 seconds).

     A client SHOULD include an Elapsed Time option in messages to
     indicate how long the client has been trying to complete a DHCP
     transaction.  Servers and Relay Agents use the data value in this
                           ^^^^^^^^^^^^^^^^
     option as input to policy controlling how a server responds to a
     client message.  For example, the elapsed time option allows a
     secondary DHCP server to respond to a request when a primary server
     hasn't answered in a reasonable time.



  ---

  I would say to keep things simple, we explicitly DISALLOW relays from
using this field??

  - Bernie

  -----Original Message-----
  From: Bernie Volz (EUD)
  Sent: Thursday, May 09, 2002 1:32 PM
  To: 'Ted Lemon'
  Cc: 'Thomas Narten'; [e-mail]
  Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option



  Ted:

  Exactly correct. And in fact from my reading of the DHCPv4 specification,
this is required by it. Here's the text from RFC 2131:

       To help
       ensure that any BOOTP relay agents forward the DHCPREQUEST message
       to the same set of DHCP servers that received the original
       DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
       value in the DHCP message header's 'secs' field and be sent to the
       same IP broadcast address as the original DHCPDISCOVER message.

  I did forget to mention that we might just need to do that - have the
server return the elapsed time option to the client!

  I don't have any issue in changing things from DHCPv4 ... I was just
assuming we MIGHT want to use that model since it has been tried and proven?

  I also agree that having the relay base the forwarding on the elapsed time
is likely bad - but again, that was assumed to happen with DHCPv4!!

  - Bernie

  -----Original Message-----
  From: Ted Lemon [mailto:[e-mail]]
  Sent: Thursday, May 09, 2002 12:55 PM
  To: Bernie Volz (EUD)
  Cc: 'Thomas Narten'; [e-mail]
  Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option



  > If the server should fail to get a Reply to the Request and restarts the
  > Solicit, time should not be reset.
  >
  > - Time is 0 when first Renew/Rebind is sent. Increases with each
  > retransmission until timeout or Reply.
  >
  > - Time is 0 when first Decline/Release is sent. Increases with each
  > retransmission until timeout or Reply.
  >
  > - Time is 0 when first Information-Request is sent. Increases with each
  > retransmission until timeout or Reply.
  >

  I think if you let the relay agent make relaying decisions based on the
  time sent by the client, you're in big trouble.   Picture this:

  client sends solicit A, t=0
  relay sends solicit to server A
  client sends solicit B, t=100
  relay sends solicit to server B
  server A responds to solicit A with advertise A
  client sends Request A, t=100
  relay sends Request A to server B
  server B drops Request A on the floor

  repeat until bored

  The only reliable way to fix this is to have the server send the time it
  received from the client in the solicit back to the client in the
advertise,
    and for the client to use that time in every subsequent Request,
  regardless of how long it has to retry.   This is complicated to specify,
  and complicated to implement.   Do we really want this?