[PATCH] udhcpc6: add support IETF RFC3315 section-19.1.2 retransmission strategy

Frank TEO frank128 at ymail.com
Fri Sep 28 08:27:58 UTC 2012


Sorry, I got the RFC3315 section number wrong for client.
It should be section 14. But very much the same concept that timeout is double of previous one for retransmission as according to the patch.
Patch does not consider RAND.

RFC3315 Section 14
The client retransmission behavior is controlled and described by the following variables:
      RT     Retransmission timeout
      IRT    Initial retransmission time
      MRC    Maximum retransmission count
      MRT    Maximum retransmission time
      MRD    Maximum retransmission duration
      RAND   Randomization factor

RT for the first message transmission is based on IRT:
      RT = IRT + RAND*IRT   (Mean: first timeout is 1sec + RAND)

RT for each subsequent message transmission is based on the previous value of RT:
      RT = 2*RTprev + RAND*RTprev  (Mean: Subsequent is 2x of prev timeout + RAND)

      if (RT > MRT)
         RT = MRT + RAND*MRT       (Mean: Upper bound of timeout is 30 sec, assume RAND=ZERO)

RFC3315 Section 18.1.1
The client transmits the message according to section 14, using the
following parameters:
      IRT   REQ_TIMEOUT
      MRT   REQ_MAX_RT
      MRC   REQ_MAX_RC

RFC3315 Section 5.5
   REQ_TIMEOUT       1 sec   Initial Request timeout
   REQ_MAX_RT       30 secs  Max Request timeout value
   REQ_MAX_RC       10       Max Request retry attempts




----- Original Message -----
From: Frank TEO <frank128 at ymail.com>
To: "busybox at busybox.net" <busybox at busybox.net>
Cc: 
Sent: Friday, 28 September 2012, 15:22
Subject: [PATCH] udhcpc6: add support IETF RFC3315 section-19.1.2 retransmission strategy

IETF RFC3315 section-19.1.2 Time Out and Retransmission said

If the server does not receive a Renew or Information-request message
from the client in REC_TIMEOUT milliseconds, the server retransmits
the Reconfigure message, doubles the REC_TIMEOUT value and waits
again. The server continues this process until REC_MAX_RC
unsuccessful attempts have been made, at which point the server
SHOULD abort the reconfigure process for that client.


Where
REC_TIMEOUT       2 secs  Initial Reconfigure timeout
REC_MAX_RC        8       Max Reconfigure attempts

udhcpc6 option to be use : -T 2 -t 8

It is up to user to decide abort or tryagain timeout after REC_MAX_RC attempt.

The attached busybox-udhcpc6-rfc3315-section-19-1-2.patch is patch without 
applying discover_retries == 0 (infinite) patch 1c7a58dfb82ea04c525e0c19f94f2d800dee99e3.

I believe "discover_retries == 0 (infinite) patch" cannot reset "packet_num = 0;" which is required by this patch.
Since I am using -t greater than 0, so I am not affected. 

diff -Naupr busybox-orig/networking/udhcp/d6_dhcpc.c busybox-new/networking/udhcp/d6_dhcpc.c
--- busybox-orig/networking/udhcp/d6_dhcpc.c    2012-08-16 22:52:27.000000000 +0800
+++ busybox-new/networking/udhcp/d6_dhcpc.c    2012-08-23 14:58:29.894235000 +0800
@@ -1116,7 +1116,7 @@ int udhcpc6_main(int argc UNUSED_PARAM, 
                         xid = random_xid();
                     /* multicast */
                     send_d6_discover(xid, requested_ipv6);
-                    timeout = discover_timeout;
+                    timeout = discover_timeout << packet_num;
                     packet_num++;
                     continue;
                 }
@@ -1143,7 +1143,7 @@ int udhcpc6_main(int argc UNUSED_PARAM, 
                 if (packet_num < discover_retries) {
                     /* send multicast select packet */
                     send_d6_select(xid);
-                    timeout = discover_timeout;
+                    timeout = discover_timeout << packet_num;
                     packet_num++;
                     continue;
                 }


http://lists.busybox.net/mailman/listinfo/busybox



More information about the busybox mailing list