Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

[VithalPrasad Gaitonde <[e-mail]>]

Agree that 3 has the best merit. In terms of number of retransmissions, it
would be preferable to go with as many retransmission (about 8?) as would
fit in a 2 minute interval (i.e. the older SOL_MAX_RT value).
Since existing deployments work with the 2 minute retransmission cycle,
this will ensure that subsequent retransmissions (beyond the first hour)
are successful.

So the proposal is - the first retransmission cycle is for 1 hour with
exponentially increasing time between retransmissions. Every subsequent
retransmission cycle which will occur after a gap of 1 hour will last for a
2 minute duration.



On Sat, Feb 16, 2013 at 8:41 AM, Dmitry Anipko
<[e-mail]>wrote:

>  My understanding is that (2) would be against one of the motivations for
> the draft – reduce load on servers, as you pointed out. ****
>
> ** **
>
> So I agree (3) would be better, if at all something needs to be done for
> this issue.****
>
> ** **
>
> *From:* Bernie Volz (volz) [mailto:[e-mail]]
> *Sent:* Friday, February 15, 2013 2:45 PM
> *To:* VithalPrasad Gaitonde
>
> *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; [e-mail]; Andre
> Kostur; Lemon Ted
> *Subject:* RE: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt****
>
>  ** **
>
> (I guess I should now start saying “WG co-chair hat off” …)****
>
> ** **
>
> Interesting points.****
>
> ** **
>
> The elapsed time option only supports 16-bits and is in 100ths of a
> second, so it will max out at 655.35 seconds (under 11 minutes).****
>
> ** **
>
> As these are a ‘retransmission’ and so the XID would be the same and the
> elapsed time should reflect the time since the client started (obviously
> maxing out at a value of 0xffff as documented in RFC 3315).****
>
> ** **
>
> Regarding the single packet issue … I see:****
>
> **1.       **Let it be. If the original retransmissions up this point
> didn’t work, what’s the chance that it will work now? And a single packet
> should generally be OK. Though there may be some ND implementations that
> drop a packet they can’t send instead of holding onto at least that one
> packet and that might cause things to fail ‘forever’ (the server-to-client
> or relay-to-client ND entry would expire before the next packet arrives).
> ****
>
> **2.       **Have the client could ‘restart’ the Solicit process instead
> of using the longer time as a cap to the retransmission delay. But this
> means that the client would send restart sending at the normal backoff
> intervals and that makes the clients (if there are a lot) very chatty in
> total – which is what we wanted to prevent. This would also mean a new XID
> and new elapsed time base.****
>
> **3.       **Complicate the retransmission algorithm to allow some small
> number (2 or 3) packets in a “shorter” interval after ‘long’ retransmission
> interval (this is what you suggested). Probably these should occur well
> within the typical ND cache expiration interval.****
>
> **4.       **Something else? (Document that not retaining a packet per
> destination when needing ND is a bad idea.)****
>
> ** **
>
> 2 may be the most attractive as it is much simpler (and means this
> document would define an MRD for Solicit too). But the long delay between
> retransmissions leading up to the maximum may also suffer from the issue
> mentioned in #1, so #3 may have the best merit.****
>
> ** **
>
> **-          **Bernie****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]<[e-mail]>]
> *On Behalf Of *VithalPrasad Gaitonde
> *Sent:* Thursday, February 14, 2013 10:14 PM
> *To:* Bernie Volz (volz)
> *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; [e-mail]; Andre
> Kostur; Lemon Ted
> *Subject:* Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt****
>
> ** **
>
> Apparently, some relay agents/switches can be configured to relay packets
> based on the amount of time the client has been trying (elapsed time
> option). Similar language exists for the behavior of the DHCP server.****
>
>  ****
>
> From RFC 3315 section 22.9 - ****
>
> Servers and Relay Agents use the data value in this option (elapsed time)
>    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 has not
>    answered in a reasonable time.****
>
>  ****
>
> When the client retransmits at every 1 hour interval, does the client
> reset the elapsed time option to 0. If yes, with the above mentioned
> behavior of relay agents and servers, the single retransmission of SOLICIT
> or INFORM will turn out inadequate.****
>
> Also, given the unreliability of UDP, doing only one retransmission of the
> message every hour (beyond the first hour) may lead to situations where the
> server does not see the request and the client has to wait for another hour
> to get an IPv6 address or options.****
>
>  ****
>
> Instead of making just a single retransmission at every 1 hour interval,
> the client should make at least a couple of retransmissions to increase the
> reliability of getting an IPv6 address or options from the server.****
>
>  ****
>
> Thanks,****
>
> Prasad****
>
> On Fri, Feb 1, 2013 at 8:10 PM, Bernie Volz (volz) <[e-mail]> wrote:
> ****
>
> Fine by me too.
>
> - Bernie****
>
>
> On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <[e-mail]>
> wrote:
>
> >>> A client is not expected to listen for a response during the entire
> period between transmission of Solicit or Information-Request messages
> >
> > Looks good to me.
> >
> > Thanks.
> >
> > -----Original Message-----
> > From: Ralph Droms [mailto:[e-mail]]
> > Sent: Friday, February 01, 2013 6:08 PM
> > To: Dmitry Anipko
> > Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; [e-mail];
> Andre Kostur; Lemon Ted
> > Subject: Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt
> >
> > (resending to dhcwg mailing list)
> >
> > On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko <
> [e-mail]>
> > wrote:
> >
> >> Agree with everything you wrote. I think several minutes waiting would
> be fine, and I understand there may be good reasons for such waiting
> interval (as opposed to hour).
> >>
> >> If there is a general agreement on these 2 adjustments (allowed waiting
> period cap and INF_MAX_RT default), how do we move forward - Ralph, can
> these be included in the next revision of the draft?
> >>
> >> Thank you.
> >
> > Adding INF_MAX_RT makes sense.
> >
> > In my opinion, the right thing to say about waiting for a response is
> something vague, to the effect of "A client is not expected to listen for a
> response during the entire period between transmission of Solicit or
> Information-Request messages."
> >
> > - Ralph
> >
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg****
>
> ** **
>