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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 8 May 2002 11:10:56 -0500

Either could work.

I think the reason time is more interesting is that usually you want to guarantee some response within a fixed time. Retransmission numbers don't reflect how long the client may have been waiting (though there is some reasonable mapping based on the retransmission algorithm).

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 11:12 AM
To: [email-masked]
Subject: [dhcwg] dhcpv6-24: Elapsed Time option

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

Would it make sense to change this option to carry the retransmission
number rather than an actual time? I.e., backup servers would respond
only on (say) a retransmission?

I understand this to be a holdover from DHC. But if the goal is to
provide backup servers info on when they should respond, the
retransmission count might be more useful than the elapsed time.

Thoughts?

Thomas

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 May 2002 13:33:10 -0500

> The DHC WG Meeting Minutes that Ralph published stated that the WG did 
> want to have load balancing for relays. I specifically asked about this 
> issue and I was promoting that we don't do it. What is your recollection?

I don't remember, but that doesn't sound incorrect.  (I think that's as 
wishy-washy an answer as I can give, but I'm open to suggestions... :')

> If we extend load balancing to relays, and load balancing includes the 
> ability to use the "elapsed-time", aren't we really asking for trouble?

Maybe I'm making this too complicated.   If the relay agent always 
_expands_ the set of servers to which it relays the packet as the retry 
time increases, it's safe.   It's only unsafe in the case where the set of 
servers (A) to which the relay agent relays at time=t is _disjoint_ with 
the set of servers (B) to which the relay agent relays at time=t+1.   As 
long as set A is a subset of set B, we're fine.   This is probably 
something that we can specify pretty safely.

> I would like to keep relays very simple in DHCPv6 and make them simply 
> forward the packets. All of the work should be done by servers, IMHO.

I think this is a good motivation, and I don't mind going this route.   
Here's what I suggest: we specify that the time in the retry time field in 
a Request message that immediately follows an Advertise message should be 
the time since the first Solicit was sent, not the time since the first 
Request message was sent.   This covers our patooties in the event that we 
change our mind on the Relay agent issue later.