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

From: VithalPrasad Gaitonde <[email-masked]>
Date: Fri, 8 Mar 2013 23:14:45 +0530

Could folks comment on the proposal below?

On Wed, Feb 27, 2013 at 12:12 AM, VithalPrasad Gaitonde
<[email-masked]>wrote:

> 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 <
> [email-masked]> 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:[email-masked]]
>> *Sent:* Friday, February 15, 2013 2:45 PM
>> *To:* VithalPrasad Gaitonde
>>
>> *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]; 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:* [email-masked] [mailto:[email-masked]<[email-masked]>]
>> *On Behalf Of *VithalPrasad Gaitonde
>> *Sent:* Thursday, February 14, 2013 10:14 PM
>> *To:* Bernie Volz (volz)
>> *Cc:* Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]; 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) <[email-masked]>
>> wrote:****
>>
>> Fine by me too.
>>
>> - Bernie****
>>
>>
>> On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <[email-masked]>
>> 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:[email-masked]]
>> > Sent: Friday, February 01, 2013 6:08 PM
>> > To: Dmitry Anipko
>> > Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; [email-masked];
>> 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 <
>> [email-masked]>
>> > 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg****
>>
>> ** **
>>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 8 Mar 2013 18:41:58 +0000

I kind of would prefer that we keep retransmissions to a minimum - I think 3 (total transmissions) is a good number (perhaps with normal 8 and 16 second backoffs - slower than normal but not that slow). It may be best to have this kick in whenever the time between retransmission is greater than several x TTL (hops - probably >5 minutes) or something like that?

The whole idea with solmax was to REDUCE the retransmissions, so we do need to be careful here not to end up increasing them. I think we should get by with only 2 transmissions (1 retransmission).

-          Bernie

From: VithalPrasad Gaitonde [mailto:[email-masked]]
Sent: Friday, March 08, 2013 12:45 PM
To: Dmitry Anipko
Cc: Bernie Volz (volz); Bud Millwood; Ralph Droms; [email-masked]; Andre Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

Could folks comment on the proposal below?
On Wed, Feb 27, 2013 at 12:12 AM, VithalPrasad Gaitonde <[email-masked]<mailto:[email-masked]>> wrote:
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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 15, 2013 2:45 PM
To: VithalPrasad Gaitonde

Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]<mailto:[email-masked]>; 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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of VithalPrasad Gaitonde
Sent: Thursday, February 14, 2013 10:14 PM
To: Bernie Volz (volz)
Cc: Bud Millwood; Dmitry Anipko; Ralph Droms; [email-masked]<mailto:[email-masked]>; 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 -
   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) <[email-masked]<mailto:[email-masked]>> wrote:
Fine by me too.

- Bernie

On Feb 1, 2013, at 9:52 PM, "Dmitry Anipko" <[email-masked]<mailto:[email-masked]>> 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.
>
> From: Ralph Droms [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Bernie Volz (volz); Bud Millwood; Sten Carlsen; [email-masked]<mailto:[email-masked]>; Andre Kostur; Lemon Ted
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt
>
> On Feb 1, 2013, at 5:59 PM 2/1/13, Dmitry Anipko <[email-masked]<mailto:[email-masked]>>
> 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.
>
> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 8 Mar 2013 19:15:12 +0000

>> The whole idea with solmax was to REDUCE the retransmissions, so we do need to be careful here not to end up increasing them. I think we should get by with only 2 transmissions (1 retransmission).

I'd agree. 8 retransmissions sound excessive/unnecessary, 2-3 total transmissions should be sufficient. The time between such transmitted packets should be larger than default allowed ND total timeout, to cover the case of packet loss due to ND being slow.

>> It may be best to have this kick in whenever the time between retransmission is greater than several x TTL (hops - probably >5 minutes) or something like that?

Another possibility is to kick this in whenever the interval between transmissions calculated using the exponential back-off is larger than the default max before solmaxrt-update.

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Friday, March 08, 2013 10:42 AM
To: VithalPrasad Gaitonde; Dmitry Anipko
Cc: Bud Millwood; Ralph Droms; [email-masked]; Andre Kostur; Lemon Ted
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

-          Bernie

From: VithalPrasad Gaitonde [mailto:[email-masked]]
Sent: Friday, March 08, 2013 12:45 PM
To: Dmitry Anipko
Cc: Bernie Volz (volz); Bud Millwood; Ralph Droms; [email-masked]<mailto:[email-masked]>; Andre Kostur; Lemon Ted
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-solmaxrt-update-00.txt

Interesting points.

-          Bernie

Thanks,
Prasad

- Bernie