Method and apparatus for controlling handshake in a packet transmission network

Abstract

The present invention relates to a method and apparatus for controlling a handshake operation. Datagram Transport Layer Security (DTLS) is an important secure protocol in the IP based Internet of things. The performance of DTLS handshake can be significantly affected by network status, traffic and packet loss rate, etc. It is therefore suggested evaluating a package loss rate and estimating causes of packet loss. Then, a DTLS handshake strategy may be changed adaptively based on the detection of packet loss and network status. As a result, the successful rate and delay of DTLS handshake can be improved. An acknowledgement and a non-acknowledgement mode may be used in a hybrid way to evaluate the package loss rate and estimate causes of packet loss and eventually improve performance of DTLS handshake.

Claims

1. An apparatus for controlling handshake in a packet transmission network, the apparatus comprising: a processor to detect packet loss in a handshake-based packet transmission and for estimating a cause of the detected packet loss, and change a handshake strategy of the packet transmission based on the estimated causes, wherein the processor estimates a packet loss rate caused by said estimated cause and to estimate a remaining time for handshake based on the packet loss rate, to compare the remaining time with a predetermined handshake timeout, changes the handshake strategy upon determination that the estimated remaining time is larger than the predetermined handshake timeout, estimates a wireless loss when the detected packet loss is distributed randomly or when delays between each received packet and respective subsequent packet of the received continuous packets are determined by the processor to be equal, and wherein, when the processor has estimated a wireless loss, then the processor estimates a packet loss rate, estimates a remaining time for handshake based on the packet loss rate, to compare the remaining time with a predetermined handshake timeout, and increases a transmission rate of the packet transmission proportional to a ratio between the estimated remaining time for handshake and the predetermined handshake timeout if the estimated remaining time is larger than the predetermined handshake timeout.

2. The apparatus of claim 1, wherein the processor detects the packet loss based on a sequence of received packets.

3. The apparatus of claim 2, wherein the processor detects the packet loss based on a sequence of ClientHello messages of a DTLS handshake signaling.

4. The apparatus of claim 1, wherein the detector processor estimates a congestion loss as the cause of the detected packet loss if a delay between received continuous packets varies or if there is a disorder between received continuous packets.

5. The apparatus of claim 4, wherein, if the processor has estimated a congestion loss, then the processor estimates a packet loss rate, estimate a remaining time for handshake based on the packet loss rate, to compare the remaining time with a predetermined handshake timeout, and to increase a transmission interval and decrease a transmission rate of the packet transmission if the estimated remaining time is larger than the predetermined handshake timeout.

6. The apparatus of claim 1, wherein, when the processor has estimated a congestion loss and when the apparatus is located on a server side of the packet transmission, then the processor notifies a client side of the packet transmission to prolong the handshake timeout.

7. The apparatus of claim 1, wherein the processor estimates the packet loss rate by calculating a total transmission time until receiving the last acknowledgement of a predetermined handshake message and using the equation $P_L=1-\frac{2}{\sqrt{N_s}},$ wherein N.sub.S denotes the calculated total transmission time and P.sub.L denotes the estimated packet loss rate.

8. The apparatus of claim 6, wherein said predetermined handshake message is a ClientHello message of a DTLS handshake signaling.

9. A method of controlling handshake in a packet transmission network, the method performed by a processor comprising: detecting packet loss in a handshake-based packet transmission; estimating causes of the detected packet loss; estimating a packet loss rate caused by said estimated cause; estimating a remaining time for handshake based on the packet loss rate; comparing the remaining time with a predetermined handshake timeout; and if the estimated remaining time is larger than the predetermined handshake timeout, changing a handshake strategy of the packet transmission based on the estimated causes, and estimating a wireless loss if the detected packet loss is distributed randomly or if delays between each received packet and respective subsequent packet of the received continuous packets are determined by the processor to be equal, and when estimated, by the processor that, a wireless loss exists, estimating a packet loss rate, estimating a remaining time for handshake based on the packet loss rate, to compare the remaining time with a predetermined handshake timeout, and increasing a transmission rate of the packet transmission proportional to a ratio between the estimated remaining time for handshake and the predetermined handshake timeout if the estimated remaining time is larger than the predetermined handshake timeout.

10. A computer program product comprising a plurality of program code portions, stored in a non-transitory computer readable medium, for carrying out the method of claim 9 when run on a computer device.

11. The method according to claim 9, further comprising the following step: if the estimated remaining time is smaller than the predetermined handshake timeout, then do not change a handshake strategy of the packet transmission based on the estimated causes.

12. The apparatus of claim 1, wherein the processor does not change the handshake strategy upon determination that the estimated remaining time is smaller than the predetermined handshake timeout.

13. The apparatus of claim 5, wherein the processor estimates the packet loss rate by calculating a total transmission time until receiving the last acknowledgement of a predetermined handshake message and using the equation $P_L=1-\frac{2}{\sqrt{N_s}},$ wherein N.sub.S denotes the calculated total transmission time and P.sub.L denotes the estimated packet loss rate.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) In the following drawings:

(2) FIG. 1 shows a schematic signaling diagram of a DTLS handshake with certificate;

(3) FIG. 2 shows a schematic block diagram of a non-acknowledged packet transmission between a client and server according to a first embodiment;

(4) FIG. 3 shows a schematic system architecture of a handover control scheme for the non-acknowledged packet transmission between a client and server according to the first embodiment;

(5) FIG. 4 shows a flow diagram of a server side processing of the handover control scheme for the non-acknowledged packet transmission according to the first embodiment;

(6) FIG. 5 shows a first message structure of a ClientHello message as used in the first embodiment;

(7) FIG. 6 shows a flow diagram of a client side processing of the handover control scheme for the non-acknowledged packet transmission according to the first embodiment;

(8) FIG. 7 shows a schematic block diagram of an acknowledged packet transmission between a client and server according to a second embodiment;

(9) FIG. 8 shows a second message structure of a ClientHello message as used in the second embodiment;

(10) FIG. 9 shows a signaling diagram of a handover interaction between a client and a server according to the second embodiment; and

(11) FIG. 10 shows a flow diagram of a server side processing of the handover control scheme for the acknowledged packet transmission according to the second embodiment.

DETAILED DESCRIPTION OF EMBODIMENTS

(12) Embodiments of the present invention are now described based on a DTLS handshake with adaptively changed handshake strategy between a server and a client.

(13) FIG. 2 shows a schematic block diagram of a non-acknowledged packet transmission between a client (C) 10 and server (S) 20 according to a first embodiment. In the case of FIG. 2, packets 15 are transmitted from the client 10 to the server 20. The server checks the sequence of received packets in order to determine lost packets 17.

(14) FIG. 3 shows a schematic system architecture of a handover control scheme for the non-acknowledged packet transmission between the client and the server according to the first embodiment. In both server and client sides there are two functional blocks. The first functional block is a detection block (or detector) C1, S1 for detection of packet loss. This functional block detects the packet loss based on the received packets and estimates a packet loss rate. The second functional block is a control block (or controller) C2, S2 for changing a transmission and receiving strategy (i.e. handshake strategy) for client messages CM1 and CM2 and for server messages SM1 and SM2 between the client (C) and the server (S). This functional block is adapted to change the handshake strategy according to the detected packet loss.

(15) Because DTLS handshake messages may be lost, DTLS needs a mechanism for retransmission. DTLS implements retransmission using a single timer at each endpoint. Each end-point keeps retransmitting its last message until a reply is received. According to the DTLS protocol, an initial timer value for the predetermined handshake timeout can be set to is (the minimum is defined in RFC 2988) and the value can be doubled at each retransmission, up to no less than a maximum of 60 seconds (as defined in RFC 2988). The current timer value can be retained until a transmission without loss occurs, at which time the value may be reset to the initial value. After a long period of idleness, no less than 10 times the current timer value, the timer may be reset to the initial value. One situation where this might occur is when a re-handshake is used after substantial data transfer.

(16) FIG. 4 shows a flow diagram of a server side processing of the handover control scheme for the non-acknowledged packet transmission according to the first embodiment. More specifically, the processing of FIG. 4 relates to a packet loss detection and strategy changing mechanism on the server side.

(17) In step S401, the server detects the packet loss based on the received packets of ClientHello and ClientHello* messages of a handshake procedure according to the DTLS protocol (i.e. DTLS handshake). Since each packet has a serial number, the server can detect the packet loss from the sequence of the packets.

(18) Then, in step S402, a decision on the type of packet loss is made. This process determines the type of loss according to the following criteria: Is there disorder between received ClientHello and ClientHello* messages? If yes, there is congestion loss. Does the delay between two continuously received packets vary? If yes, there is congestion loss. Is the packet loss distributed randomly or is the delay almost equal? If yes, there is wireless loss.

(19) If a wireless loss is determined in step S402, the procedure branches to step S413 where the packet loss rate is estimated based on received packets by using the following equation:

(20) $\begin{array}{cc}=\frac{\mathrm{Number}\mathrm{of}\mathrm{lost}\mathrm{packets}}{\mathrm{Total}\mathrm{number}\mathrm{of}\mathrm{expected}\mathrm{received}\mathrm{packets}}& \left(1\right)\end{array}$

(21) Then, in step S414, the remaining time for the handshake is estimated by using the following equations:
D.sub.e=(N.sub.e()3)*(2)
where N.sub.e=N(m=1)+N(m=24)+N(m=27)(3)

(22) and where denotes the transmission interval and

(23) $=\frac{1}{R}$
and where R denotes the transmission rate.

(24) In equation (3), N(m=k) designates expected transmission times for successfully receiving m packets by a receiver. The receiver has a buffer to store the received packets. Each packet has a sequence number. Each time, the m packets are sent together. This transmission strategy can be found in Section 4.2.3 of specification RFC 4347, Datagram Transport Layer Security (http://tools.ietf.org/html/rfc4347).

(25) It is known that the expected transmission time N(m=k) depends on the packet loss rate. It can be show that:

(26) $\begin{array}{cc}N\left(m=1\right)=\frac{1}{1-\mathrm{PL}}& \left(4\right)\\ N\left(m=2\right)=\frac{1+2\mathrm{PL}}{1-{\mathrm{PL}}^2}& \left(5\right)\\ N\left(m\right)=\underset{k=1}{\overset{m}{.Math.}}\left(\begin{array}{c}m\\ k\end{array}\right){\left(-1\right)}^{k-1}\frac{1}{1-{\mathrm{PL}}^k}& \left(6\right)\end{array}$

(27) As an alternative, values for N(m=24) and N (m=27) can be obtained from a computer simulation.

(28) Then, in step S415, the estimated remaining handshake time D.sub.e and a predetermined handshake timeout D.sub.r are compared. If it is determined in step S415 that the estimated remaining handshake time D.sub.e is smaller than the predetermined handshake timeout D.sub.r, i.e., D.sub.e<D.sub., then the procedure branches to step S416 and the transmission rate is not changed. Otherwise, the procedure branches to step S417 and the transmission rate is increased. As an example, the amount of increase can be calculated by using the following equation:

(29) $\begin{array}{cc}R:=R*\frac{D_e}{D_r}*2& \left(7\right)\end{array}$

(30) Otherwise, if a congestion loss is determined in step S402, the procedure branches to step S403 where the packet loss rate is estimated based on received packets by using the above equation (1). Thereafter, in step S404, the remaining time for the handshake is estimated by using the above equations (2) and (3).

(31) Then, in step S405, the estimated remaining handshake time D.sub.e and the predetermined handshake timeout D.sub.r are compared. If it is determined in step S405 that the estimated remaining handshake time D.sub.e is smaller than the predetermined handshake timeout D.sub.r, i.e., D.sub.e<D.sub.96, then the procedure branches to step S406 and the transmission rate is not changed. Otherwise, the procedure branches to step S407 where 27 packets are sent one by one with a predetermined interval where >process deicty of one node. Then, the transmission interval is increased and the transmission rate is decreased. As an example, the amount of decrease can be calculated by using the following equation:

(32) $\begin{array}{cc}R:=\frac{R}{2}& \left(8\right)\end{array}$

(33) Furthermore, the client side can be notified to prolong the handshake timeout. As an example, the handshake timeout may be doubled, i.e. D.sub.r:=D.sub.*2. The notification can be defined as an extension in the ServerHello message of the DTLS handshake. FIG. 5 shows a first message structure of a ClientHello message as used in the first embodiment. The ClientHello message contains a protocol version (PV) of 2 bytes (2B) length, a random section (Rd) of 32 bytes (32B) length with time (t) and random (R) parameters, a session identity (S-ID) of 0 to 32 bytes length, a cipher suite parameter (CS) of 2 bytes length, a compression method (CM) parameter of 1 byte length, and an extension (EXT) field with type (T) and extension (Ext) portion.

(34) FIG. 6 shows a flow diagram of a client side processing of the handover control scheme for the non-acknowledged packet transmission according to the first embodiment.

(35) In step S601, packet loss determination on the client side is performed. The determination on the client side can be based on a notification from the server side about the packet loss or on a direct detection of the packet loss based on the packets received from the server including server messages such as HelloVerifyRequest, Certificate and ServerHelloDone. Since each packet has a serial number, the client can detect the packet loss from the sequence of the packets.

(36) Then, in step S602, a decision on the type of loss is made. The type of loss may based on the following criteria Does the delay between two continuous receiving vary? If yes, there is congestion loss. Is the packet loss distributed randomly or is the delay almost equal? If yes, there is wireless loss.

(37) If a wireless loss is determined in step S602, the procedure branches to step S613 where the packet loss rate is estimated based on received packets by using the above equation (1).

(38) Then, in step S614, the remaining time for the handshake is estimated by using the following equations:
D.sub.e=(N.sub.e()2)*(9)
where N.sub.e=N(m=1)+N(m=24)(10)

(39) and where denotes the transmission interval and

(40) $=\frac{1}{R}$
and where R denotes the transmission rate.

(41) In equation (10), N(m=k) designates expected transmission times for successfully receiving m packets by a receiver, as explained above in connection with equations (4) to (6). As an alternative, value for N(m=24) can be obtained from a computer simulation.

(42) Then, in step S615, the estimated remaining handshake time D.sub.e and a predetermined handshake timeout D.sub.r are compared. If it is determined in step S615 that the estimated remaining handshake time D.sub.e is smaller than the predetermined handshake timeout D.sub.r, i.e., D.sub.e<D.sub., then the procedure branches to step S616 and the transmission rate is not changed. Otherwise, the procedure branches to step S617 and the transmission rate is increased. As an example, the amount of increase can be calculated by using the above equation (7).

(43) Otherwise, if a congestion loss is determined in step S602, the procedure branches to step S603 where the packet loss rate is estimated based on received packets by using the above equation (1). Thereafter, in step S604, the remaining time for the handshake is estimated by using the above equations (2) and (3).

(44) Then, in step S605, the estimated remaining handshake time D.sub.e and the predetermined handshake timeout D.sub.r are compared. If it is determined in step S605 that the estimated remaining handshake time D.sub.e is smaller than the predetermined handshake timeout D.sub.r, i.e., D.sub.e<D.sub., then the procedure branches to step S606 and the transmission rate is not changed. Otherwise, the procedure branches to step S607 where 24 packets are sent one by one with the predetermined interval where >process deicty of one node. Then, the transmission interval is increased and the transmission rate is decreased. As an example, the amount of decrease can be calculated by using the above equation (5).

(45) Furthermore, the handshake timeout can be prolonged. As an example, the handshake timeout may be doubled, i.e. D.sub.r:=D.sub.r*2.

(46) FIG. 7 shows a schematic block diagram of an acknowledged packet transmission between a client (C) 10 and a server (S) 20 according to a second embodiment.

(47) In the second embodiment, it is proposed to use a dynamic acknowledgement message or packet (ACK) 16 to acknowledge receipt of a packet 15 and thereby shorten the delay. Moreover, the ACK 16 can be used to estimate packet loss and adjust the transmission strategy accordingly. In both server and client sides there are now three functional blocks to improve DTLS performance in an IP based network. The first functional block is a request block (or requestor) for providing an adaptive request of acknowledgement. The second block is a detection module (or detector) which can calculate the network packet loss rate and estimate the causes of network packet loss based on the calculated packet loss rate, e.g., by using the above equations (4) to (6). The third block is a control block (or controller) which can change the DTLS handshake strategy based on the detection of packet loss and possible causes of the loss.

(48) FIG. 8 shows a second message structure of a ClientHello message as used in the second embodiment. In addition to the fields and parameters of FIG. 5, the second message structure of the ClientHello message contains a cookie field (CK) of 0 to 32 bytes length. The adaptive request for ACK can be defined and signaled in the extension field (EXT), e.g. as a binary flag with value 0 or 1. The server may then take action in response to the receipt of an ACK request in the following manner: ACK=1 the server needs to send ACK back to the client; ACK=0 the server does not need to send ACK back to client.

(49) FIG. 9 shows a signaling diagram of a handover interaction between a client and a server according to the second embodiment. The initial ClientHello message is split into two parts p1 and p2 which are both acknowledged by an ACK and the HelloVerifyRequest message, respectively. Additionally, the subsequent ClientHello* message is split into three parts p1 to p3, of which two are acknowledged by ACKs and the last one is acknowledged by a server message, e.g., ServerHello.

(50) In the handshake interaction signalling according to the second embodiment, only the messages ClientHello and ClientHello* comprise an ACK request. The client and server can use records of sent packets and received packets to detect packet loss and estimate the packet loss rate.

(51) FIG. 10 shows a flow diagram of a server-side processing of the handover control scheme for the acknowledged packet transmission according to the second embodiment. The client side can have a similar approach by detecting the ACK and HelloVerifyRequest message.

(52) In step S1001, the packet loss is detected. The following approaches may be used to detect packet loss at both client and server sides.

(53) If a timeout is detected, the client needs to retransmit the packet. The client can calculate the whole transmission times N.sub.e until receiving the last ACK of ClientHello* from server.

(54) The client can then estimate the packet loss rate by using the following equations:

(55) $\begin{array}{cc}{N}_c=\frac{4}{{\left(1-P_L\right)}^2}& \left(11\right)\\ P_L=1-\frac{2}{\sqrt{N_c}}& \left(12\right)\end{array}$

(56) After receiving the first part (p1) of the ClientHello message, the server will send an ACK. If there is timeout, the server needs to retransmit the packet. The server can calculate the whole transmission times N.sub.S until receiving part 3 (p3) of the ClientHello* message from the client. The server can then estimate the packet loss rate by using the following equations:

(57) $\begin{array}{cc}{N}_s=\frac{4}{{\left(1-P_L\right)}^2}& \left(13\right)\\ P_L=1-\frac{2}{\sqrt{N_s}}& \left(14\right)\end{array}$

(58) Both the client and server will then change the transmission strategy according to the result of the detected packet loss.

(59) In step S1002, a decision on the type of loss is made. This process determines the type of loss according to the following criteria: Is there disorder between received ClientHello and ClientHello* messages? If yes, there is congestion loss. Does the delay between two continuously received packets vary? If yes, there is congestion loss. Is the packet loss distributed randomly or is the delay almost equal? If yes, there is wireless loss.

(60) If a wireless loss is determined in step S1002, the procedure branches to step S1013 where the packet loss rate is estimated as explained above in connection with equations (13) and (14). Then, in step S1014, the remaining time for the handshake is estimated by using the following equations:
D.sub.e=(N.sub.e(P.sub.L)3)*(15)
where N.sub.e=N(m1)+N(m=24)+N(m=27)(16)

(61) and where denotes the transmission interval and

(62) 0$=\frac{1}{R}$
and where R denotes the transmission rate.

(63) In equation (16), (m=k) designates expected transmission times for successfully receiving m packets by a receiver, as explained above in connection with equations (4) to (6). As an alternative, values for N (m=24) and N(m=27) can be obtained from a computer simulation.

(64) Then, in step S1015, the estimated remaining handshake time D.sub.e and a predetermined handshake timeout D.sub.r are compared. If it is determined in step S1015 that the estimated remaining handshake time D.sub.e is smaller than the predetermined handshake timeout D.sub.r, i.e., D.sub.e<D.sub., then the procedure branches to step S1016 and the transmission rate is not changed. Otherwise, the procedure branches to step S1017 and the transmission rate is increased. As an example, the amount of increase can be calculated by using the above equation (7).

(65) Otherwise, if a congestion loss is determined in step S1002, the procedure branches to step S1003 where the packet loss rate is estimated based on received packets by using the above equation (1). Thereafter, in step S1004, the remaining time for the handshake is estimated by using the above equations (13) and (14).

(66) Then, in step S1005, the estimated remaining handshake time D.sub.e and the predetermined handshake timeout D.sub.r are compared. If it is determined in step S1005 that the estimated remaining handshake time D.sub.e is smaller than the predetermined handshake timeout D.sub.r, i.e., D.sub.e<D.sub., then the procedure branches to step S1006 and the transmission rate is not changed. Otherwise, the procedure branches to step S1007 where the packets are sent one by one with a predetermined interval where >process deicty of one node. Then, the transmission interval is increased and the transmission rate is decreased. As an example, the amount of decrease can be calculated by using the above equation (8).

(67) Furthermore, the client side can be notified to prolong the handshake timeout. As an example, the handshake timeout may be doubled, i.e. D.sub.:=D.sub.*2. The notification can be defined as an extension in the ServerHello message or part 3 of the ClientHello* message of the DTLS handshake.

(68) Thus, according to the second embodiment, DTLS handshake performance is improved by using a hybrid transmission method in such a way that only ClientHello and ClientHello* require an ACK. The messages with long packets, such as Certificate do not need ACK, which shortens the delay of handshake. Furthermore, the packets and ACKs are used to estimate the packet loss rate. The calculated packet loss rate is used to adjust the transmission strategy so as to improve the performance of DTLS handshake.

(69) To summarize, a method and apparatus for controlling a handshake operation have been described. DTLS is an important secure protocol in the IP based Internet of things. The performance of DTLS handshake can be significantly affected by network status, traffic and packet loss rate, etc. It is therefore suggested evaluating a package loss rate and estimating causes of packet loss. Then, the DTLS handshake strategy may be changed adaptively based on the detection of packet loss and network status. As a result, the successful rate and delay of DTLS handshake can be improved. An acknowledgement and a non-acknowledgement mode may be used in a hybrid way to evaluate the package loss rate and estimate causes of packet loss and eventually improve performance of DTLS handshake.

(70) While the invention has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. The invention is not limited to the disclosed embodiments. The proposed handshake processing can be applied to and possibly standardized in other IP based security protocols or IP or lighting control or Internet of things handshake-related applications.

(71) Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word comprising does not exclude other elements or steps, and the indefinite article a or an does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

(72) The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the invention may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects of the invention with which that terminology is associated.

(73) A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

(74) The described operations like those indicated in FIGS. 4, 6 and 10 can be implemented as program code means of a computer program and/or as dedicated hardware. The computer program may be stored and/or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.