Communication device, processing method, and program

Abstract

A communication device for transmitting data to a counter device via a network, said communication device comprising a processing unit that calculates an expected transmission rate expected during non-congestion on the basis of the amount of transmission data that has not been acknowledged and a value relating to a round-trip delay time, calculates an estimated reception rate on the basis of the amount of transmission data that has been acknowledged, and determines that congestion has occurred in the network if the expected transmission rate exceeds the estimated reception rate.

Description

Communication device, processing method, and program

[0001] The present invention relates to a technique for bandwidth control in a communication system.

[0002] Advances in autonomous driving technology are making headway, and Level 4 public road driving, in which the system takes the lead in driving in limited areas, is becoming a reality.

[0003] On the other hand, for safety reasons, it is necessary to establish a remote monitoring system when the vehicle is unmanned. Remote monitoring involves various communications with different bandwidths and allowable communication delays, such as monitoring the inside and outside of the vehicle using video and audio, monitoring vehicle driving information, and emergency calls. These communications must be transmitted over mobile networks, which have large latency and bandwidth fluctuations.

[0004] In such an environment, it is necessary to guarantee the QoS requirements for the highest priority communications, such as emergency calls and vehicle monitoring, even if quality degradation occurs. On the other hand, other communications, such as video surveillance, must be transmitted as clearly and uninterruptedly as possible, so it is necessary to utilize as much communication bandwidth as possible.

[0005] Typical QoS control methods include priority control or bandwidth control on communication paths. For example, policing and shaping control bandwidth by buffering or discarding packets when traffic exceeds a certain amount.

[0006] In addition, in Strict Priority Queuing, Weighted Fair Queuing, Class Based Queuing, and the like, priority control and bandwidth control are performed by setting the priority, weight, token amount, etc. for each communication class.

[0007] However, in all of the above control methods, control must be implemented at the location where congestion occurs, and the bottleneck bandwidth must be identified before setting the limit bit rate, etc.

[0008] If the control parameters (limit bit rate, etc.) are set too low, the QoS of prioritized communications can be guaranteed, but the overall bandwidth utilization efficiency will decrease, and if they are set too high, the QoS of prioritized communications cannot be guaranteed.

[0009] In addition, in recent years, protocols such as HTTP / 2 and HTTP / 3 that multiplex communication flows using a single TCP or QUIC connection have become popular, but since the multiplexed flows are transferred using the same IP address and port number, it is difficult to identify the flow.

[0010] A Stream-Aware Multipath QUIC Scheduler for Heterogeneous Paths, EPIQ'18, 2018A Multipath QUIC Scheduler for Mobile HTTP / 2, APNet'19, 2019A Stream-Aware MPQUIC Scheduler for HTTP Traffic in Mobile Networks, IEEE Trans. Wireless communications, 2023

[0011] Techniques for utilizing the priority set in the HTTP / 2 or HTTP / 3 application layer (https: / / www.rfc-editor.org / rfc / rfc9218.html) for priority control and path selection in the transport layer have been proposed, for example, in Non-Patent Documents 1 to 3.

[0012] In the above technology, the priority of the HTTP layer is mapped to the priority of each stream in the QUIC layer, and weighting is performed using a weighted round-robin (WRR)-based algorithm. Furthermore, packet scheduling is performed with streams in mind. Since control is performed within the transport layer on the sending side where flows are multiplexed, these technologies enable flow identification and priority control.

[0013] However, if the transmission order and frequency for each stream are simply controlled, when the entire connection becomes congested, all streams will be affected by the congestion.

[0014] Conventional congestion detection detects congestion by detecting increased packet loss and delays, but it cannot detect congestion quickly due to factors such as network buffers, and it also tends to overestimate the bottleneck bandwidth. As a result, conventional technologies have the problem of being unable to control bandwidth in accordance with the fluctuating bottleneck bandwidth and guarantee the QoS requirements for prioritized communications. In other words, conventional technologies have been unable to perform appropriate bandwidth control in communication systems.

[0015] The present invention has been made in view of the above points, and has an object to provide a technique that enables appropriate bandwidth control in a communication system.

[0016] According to the disclosed technology, there is provided a communication device that transmits data to a counterpart device via a network, the communication device including a processing unit that calculates an expected transmission rate that is expected in a non-congestion state based on the amount of transmission data that has not been acknowledged and a value related to a round-trip delay time, calculates an estimated reception rate based on the amount of transmission data that has been acknowledged, and determines that congestion has occurred in the network when the expected transmission rate exceeds the estimated reception rate.

[0017] According to the disclosed technology, a technology is provided that enables appropriate bandwidth control in a communication system.

[0018] FIG. 1 is a diagram showing an example of the configuration of a communication system according to an embodiment of the present invention. FIG. 2 is a diagram showing an example of the configuration of a communication device 100. FIG. 3 is a diagram showing a first registration example of a flow / QoS class DB 120. FIG. 4 is a diagram showing a processing flow of a transmission control unit 130. FIG. 5 is a diagram showing a second registration example of a flow / QoS class DB 120. FIG. 6 is a diagram showing another example of the configuration of the communication device 100. FIG. 7 is a diagram showing an example of the hardware configuration of the communication device 100.

[0019] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0020] Hereinafter, a technique for improving bandwidth utilization while guaranteeing the QoS requirements of prioritized communications in a communications system that transfers communications of multiple flows with different priorities and QoS requirements will be described.

[0021] In this embodiment, in order to solve the above-mentioned problem, a communication device 100 on the transmitting side in a communication system estimates congestion from transport layer information and performs priority control or bandwidth control only when congestion occurs. The congestion estimation and bandwidth control performed by the communication device 100 are outlined below.

[0022] <Congestion Estimation> Each time data is transmitted, the communication device 100 calculates an expected transmission rate and an estimated reception rate assuming no congestion, and determines that congestion has occurred if the estimated reception rate is lower than the expected transmission rate.

[0023] The expected transmission rate is, for example, "amount of transmitted data that has not yet been acknowledged (inflight) / minimum RTT (corresponding to propagation delay in a non-congestion state)."

[0024] The estimated reception rate is calculated, for example, from the amount of data for which an acknowledgement is received per unit time.

[0025] <Bandwidth Control> The communication device 100 imposes a transmission restriction using a maximum inflight value that differs for each priority class, based on the estimated reception rate when it is determined that congestion has occurred.

[0026] Specifically, the bottleneck bandwidth is limited to a certain percentage or a certain value without adjusting parameters such as the token allocation amount and burst amount, or monitoring the transmission rate for each class. Also, the bandwidth limit is increased or decreased depending on the degree of deterioration of quality (RTT, packet loss, receiving rate).

[0027] The configuration and operation of the system / apparatus according to this embodiment will be described in detail below.

[0028] 1 shows an example of the configuration of a communication system according to this embodiment. In this communication system, two communication devices 100A and 100B communicate via networks 10 and 20 using a connection based on a transport protocol such as TCP or QUIC. In this communication system, congestion is detected within the transport layer, and priority control or bandwidth control is performed based on the priority or QoS requirements for each flow only when congestion occurs.

[0029] Note that this embodiment is based on a protocol such as TCP or QUIC in which the data receiving side sends a confirmation, but the technology according to this embodiment can be implemented by sending a confirmation response even when using transport protocols other than TCP or QUIC, such as UDP, or even when no transport protocol is used.

[0030] As shown in Fig. 1, a plurality of applications (software) exist in the communication system of this embodiment. In the example of Fig. 1, applications 1, 1', and 3' run within communication device 100. Applications 2, 3, and 2' run on devices different from communication device 100. For example, application 2 communicates with opposing application 2' via communication device 100A, network 10, and communication device 100B.

[0031] One or more networks and one or more transport connections exist between the communication devices 100. In addition, in this communication system, a protocol that bundles multiple transport connections, such as MPTCP or MPQUIC, may be used.

[0032] (Configuration Example of Communication Apparatus 100) Fig. 2 shows a configuration example of the transmitting side of the communication apparatus 100. For example, if the communication apparatus 100A in Fig. 1 is the transmitting side, the communication apparatus 100 in Fig. 2 corresponds to the configuration of the communication apparatus 100A in Fig. 1.

[0033] 2, the communication device 100 includes a flow buffer 110, a flow / QoS class DB 120, a transmission control unit 130, a transmitting / receiving unit 140, an acknowledgment processing unit 150, a transmission rate estimation unit 160, and a reception rate estimation unit 170. The "transmission control unit 130, the acknowledgment processing unit 150, the transmission rate estimation unit 160, and the reception rate estimation unit 170" may also be referred to as a "processing unit."

[0034] The flow buffer 110 stores communication data (packets) sent from an application. The flow buffer 110 may be provided independently for each flow (a group of related data such as the same application, 5 tuples, or streams), or a single flow buffer 110 may store data for multiple flows, with flow information provided as metadata for each data.

[0035] The flow / QoS class DB 120 manages the priority and QoS information for each flow. The QoS information includes, for example, "priority, permitted transmission ratio, minimum guaranteed ratio, maximum permitted transmission rate, allowable delay, etc." for each QoS class. This information is assumed to be registered in advance in the flow / QoS class DB 120. Note that the QoS class may also be called a priority class.

[0036] Regarding the method of storing data, any data structure may be adopted as long as QoS information corresponding to a flow identifier (such as an IP address, a port number, or a QUIC Stream ID) can be acquired. In other words, the QoS information of a flow can be acquired from the flow / QoS class DB 120 based on the flow identifier.

[0037] The transmission control unit 130 performs transmission control such as congestion control, flow control, and QoS control. The transmission control unit 130 also obtains data from the flow buffer 110 and determines whether the data can be transmitted. If the data can be transmitted, the data is transmitted to the network via the transmission / reception unit 140.

[0038] The acknowledgement processing unit 150 receives the acknowledgement received by the transmitting / receiving unit 140 from the opposing communication device 100, and performs packet loss and retransmission determination, etc.

[0039] The transmission rate estimation unit 160 calculates the expected transmission rate when there is no congestion. The reception rate estimation unit 170 estimates the reception rate per unit time from the amount of data acknowledged. This reception rate is the reception rate at which the receiving communication device 100 receives data.

[0040] (Registration Example 1 of Flow / QoS Class DB 120) Figures 3 and 4 show a first example of data registration in the flow / QoS class DB 120. Figure 3 shows the communication identifier and priority for each flow. Figure 4 shows the "priority, permitted transmission ratio, minimum guaranteed ratio, minimum guaranteed transmission rate, maximum permitted transmission rate, allowable delay, etc." for each QoS class.

[0041] (Processing flow of the transmission control unit 130) Next, a processing flow of the transmission control unit 130 will be described. Each time data is transmitted, the transmission control unit 130 performs congestion estimation, selection of transmission data, and control of the amount of inflight according to the flow shown in Fig. 5. Note that the flow omits processing generally performed by TCP, QUIC, etc.

[0042] 5, in S101, the transmission control unit 130 performs congestion estimation. In S102, the transmission control unit 130 selects transmission data from the flow buffer 110. As will be described later, this processing makes it possible to perform priority control or bandwidth guarantee.

[0043] If there is no congestion (no in S103), the process ends, and if there is congestion (yes in S103), the process proceeds to S104. In S104, the transmission control unit 130 performs an Inflight amount control (bandwidth control).

[0044] 5 is an example. For example, congestion estimation may be performed after the selection of transmission data. Each process in the flow will be described in more detail below.

[0045] (Congestion Estimation Method) First, the congestion estimation method will be described.

[0046] Each time the acknowledgment processing unit 150 receives an acknowledgment from a counterpart device (a device that receives transmission data) of the communication device 100, it calculates the latest RTT value from the transmission time of the transmission data corresponding to the acknowledgment. Furthermore, the acknowledgment processing unit 150 calculates a smoothed RTT (SRTT) which is an exponential moving average of the latest RTT value, and an RTT (RTT) which is an exponential moving average of the deviation of the latest RTT value from the SRTT. ｖａｒ and further updates the minimum RTT value within a certain period of time, ｍｉｎ Update.

[0047] The reception rate estimating unit 170 calculates an estimated reception rate per unit time from the amount of transmission data that has been acknowledged (the amount of transmission data that has arrived at the opposite device).

[0048] The transmission rate estimation unit 160 calculates the current amount of unacknowledged transmitted data (inflight) and the RTT. ｍｉｎ and RTT ｖａｒ From this, the expected transmission rate expected in a non-congestion state is calculated using the following formula: In the following formula, α is a coefficient for taking into account the amount of variation in RTT.

[0049] Expected sending rate = inflight / (RTT ｍｉｎ +αRTT ｖａｒ ) RTT ｍｉｎ can be considered as the round trip delay time when no congestion occurs, and the amount of data currently being sent, Inflight, is the RTT ｍｉｎ Dividing by this gives the transmission rate per unit time that should be obtained when there is no congestion. ｖａｒ is added to accommodate environments such as mobile networks where RTT fluctuates greatly and the minimum RTT value is not always achieved even when there is no congestion.

[0050] The transmission control unit 130 acquires the expected transmission rate and the estimated reception rate each time data is transmitted, and if the expected transmission rate exceeds the estimated reception rate, it determines that congestion has occurred and activates bandwidth control.

[0051] When the transmission bit rate of an application is rate-limiting, the expected transmission rate is approximately the same as the estimated reception rate. If the amount of acknowledgments decreases due to congestion, the estimated reception rate immediately falls below the expected transmission rate. Therefore, the technology according to this embodiment enables early congestion detection.

[0052] The expected transmission rate is calculated using the RTT ｍｉｎ and RTT ｖａｒ Instead, a target value of the delay to be suppressed may be used.

[0053] (Transmission Data Selection Method) Next, an example of a transmission data selection method will be described.

[0054] The transmission control unit 130 determines from which flow buffer 110 data should be transmitted based on the information acquired from the flow / QoS class DB 120. This makes it possible to perform priority control or guarantee bandwidth.

[0055] For example, the transmission control unit 130 can perform control equivalent to strict priority queuing by always transmitting data from a flow with a higher priority.

[0056] In addition, the transmission control unit 130 monitors the transmission rate for each QoS class, and prioritizes data transmission from the flow buffer 110 of a QoS class whose transmission rate is equal to or lower than the minimum guaranteed transmission rate set for the QoS class, thereby making it possible to guarantee the minimum transmission rate.

[0057] In addition, instead of the minimum guaranteed transmission rate, the transmission control unit 130 prioritizes data transmission from the flow buffer 110 of a QoS class that is equal to or lower than the minimum guaranteed ratio set for the QoS class relative to the estimated reception rate at the time of congestion determination, thereby making it possible to guarantee a certain percentage of the bottleneck bandwidth during congestion.

[0058] (Bandwidth Control Method 1) Next, an example of a bandwidth control method to be implemented when congestion exists will be described. In this embodiment, there are bandwidth control methods 1 to 3 as examples, and each will be described. First, bandwidth control method 1 will be described.

[0059] The estimated reception rate when congestion is determined can be regarded as the bottleneck bandwidth of the currently used transport connection.

[0060] First, the transmission control unit 130 multiplies the estimated reception rate at the time of congestion determination by the target round-trip delay time to determine the maximum transmission amount (maximum inflight value) that can be transmitted over the entire connection without waiting for an acknowledgment. The maximum inflight value means the maximum amount of data that can be transmitted without exceeding the target round-trip delay time.

[0061] The target round trip delay time is RTT, which is equivalent to the RTT during non-congestion. ｍｉｎ +αRTT ｖａｒ Alternatively, the minimum value of the allowable delay values ​​registered in the flow / QoS class DB 120 may be used, or a target value of the delay to be suppressed may be set.

[0062] Next, the transmission control unit 130 acquires the transmission permission rate corresponding to the QoS class of the data to be transmitted from the flow / QoS class DB 120, and sets the value obtained by multiplying the transmission permission rate by the maximum inflight value as the maximum inflight value of the QoS class. If the current inflight value of the QoS class exceeds the maximum inflight value of the QoS class, the transmission control unit 130 does not transmit the data.

[0063] The transmission control unit 130 can calculate the maximum inflight value for each QoS class by acquiring the permitted transmission rate corresponding to the QoS class and multiplying the maximum inflight value by the permitted transmission rate.

[0064] For example, if the maximum inflight value is 500 kB and the transmission permission ratio is 80%, transmission will only occur if the inflight value is 400 kB or less. Since there is a margin of 100 kB in the inflight value to maintain the target round-trip delay time for the entire connection, bandwidth can be reserved for communications with higher priority.

[0065] With the above method, there is no need to monitor the transmission rate for each class or to set detailed parameters (adjust the amount of tokens granted or burst amount), and it is possible to keep the data volume to a certain percentage of the bottleneck bandwidth simply by comparing it with the maximum inflight value for each QoS class.

[0066] If the maximum inflight value exceeds the congestion window value managed by TCP or QUIC, the congestion window value is set as the upper limit.

[0067] (Bandwidth Control Method 2) Next, we will explain bandwidth control method 2. In bandwidth control method 2, the transmission control unit 130 performs control to increase the amount of bandwidth to be restricted depending on the degree of congestion. This is expected to quickly resolve congestion.

[0068] Specifically, for example, the transmission control unit 130 monitors communication quality such as the transport layer's "RTT, packet loss rate, estimated reception rate," and reduces the transmission permission ratio or maximum permitted transmission rate based on the degree of deterioration of the communication quality, thereby increasing or decreasing the restricted bandwidth amount according to the degree of deterioration of congestion.

[0069] 6 shows a second registration example of the flow QoS class DB 120 in the case where the permitted transmission rate is reduced based on an increase in the RTT of the transport layer. That is, FIG. 6 shows an example in which the permitted transmission rate is set for each RTT.

[0070] Alternatively, instead of determining a limit amount for each quality level in advance, the maximum inflight value for each QoS class may be calculated and multiplied by the reciprocal of the RTT, etc., so that the maximum inflight value decreases as the RTT increases.

[0071] (Bandwidth Control Method 3) Next, we will explain bandwidth control method 3. In bandwidth control method 3, the transmission control unit 130 sets the maximum inflight value for each QoS class to the product of the maximum allowable transmission rate for each QoS class and the target round-trip delay time. This makes it possible to always set the upper limit transmission rate to a constant value, rather than as a ratio to the bottleneck bandwidth.

[0072] (Combination of Bandwidth Control Methods 1 to 3) Bandwidth control methods 1 to 3 can be arbitrarily combined. For example, by taking the minimum value between the maximum inflight value for each QoS class calculated by bandwidth control method 1 and the maximum inflight value for each QoS class calculated by bandwidth control method 3, it becomes possible to permit data transmission up to a certain transmission rate or a certain percentage of the bottleneck bandwidth.

[0073] (Other Configuration Examples) Fig. 7 shows another configuration example of the communication device 100. The communication device 100 shown in Fig. 7 shows an example in which control is performed across a plurality of transport connections.

[0074] As shown in FIG. 7, the communication device 100 in this example includes applications 1 to 4, transport control units 200-1 to 200-4, NICs 210 and 220, a flow / QoS class DB 120, a transmission control unit 130, and a transmission / reception rate estimation unit 180.

[0075] Each transport control unit 200 receives data from an application via a socket interface or the like, and performs communication control based on TCP, QUIC, or the like to transmit and receive data from the NIC 210 or NIC 220 to the network.

[0076] The transmission and reception rate estimator 180 acquires information such as the inflight value from each transport controller 200, and calculates an expected transmission rate and an estimated reception rate. In other words, the transmission and reception rate estimator 180 has the functions of the transmission rate estimator 160 and the reception rate estimator 170.

[0077] The transmission control unit 130 controls transmission by regarding multiple transport control units 200 that share a bottleneck link as a single transport control unit 200. For example, the transmission control unit 130 may determine that multiple transport control units 200 that use the same NIC are multiple transport control units 200 that share a bottleneck link. The transmission control unit 130 may also determine whether multiple transport control units 200 share a bottleneck link based on the sending and receiving addresses of the flow, etc.

[0078] (Hardware Configuration Example) The communication device 100 described in this embodiment can be realized, for example, by causing a computer to execute a program. This computer may be a physical computer or a virtual machine on a cloud.

[0079] That is, communication device 100 can be realized by using hardware resources such as a CPU and memory built into a computer to execute a program corresponding to the processing performed by communication device 100. The program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The program can also be provided via a network such as the Internet or email.

[0080] Fig. 8 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 8 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected via a bus B. The computer may further include a GPU.

[0081] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0082] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when an instruction to start the program is received. The CPU 1004 realizes functions related to the communication device 100 in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network, etc. The display device 1006 displays a GUI (Graphical User Interface) or the like according to the program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operation instructions. The output device 1008 outputs the results of calculations.

[0083] (Summary, Effects, etc. of the Embodiments) As described above, the technology described in the present embodiments enables appropriate bandwidth control in a communication system. That is, even in an environment where the bottleneck bandwidth fluctuates, it becomes possible to improve bandwidth utilization while guaranteeing the QoS requirements (e.g., delay, bandwidth, loss) of prioritized communication without having to know the bottleneck bandwidth in advance.

[0084] Bandwidth control is lightweight and fast because it only needs to check whether the amount of Inflight exceeds a threshold at the time of transmission. Furthermore, token management and calculation of transmission rates for each flow are unnecessary, making it possible to operate lightweight and fast.

[0085] Furthermore, in the technology according to the present embodiment, QoS control can be performed in cooperation with the transport layer, and therefore QoS control is possible for each flow even if the flows are multiplexed using QUIC, etc. Furthermore, in the technology according to the present embodiment, control is performed by the communication device 100 on the sending side, and therefore there is no need to implement special functions in each device on the communication path.

[0086] In addition, as a result of conducting experiments using the technology according to this embodiment, it has been confirmed that it is possible to suppress delays in priority flows while ensuring throughput for low-priority communications in an environment where bottleneck bandwidth fluctuates.

[0087] The following additional notes are provided regarding the above-described embodiments.

[0088] <Supplementary Notes> (Supplementary Item 1) A communications device that transmits data to a counterpart device via a network, comprising: a memory; and at least one processor connected to the memory, wherein the processor calculates an expected transmission rate expected in a non-congestion state based on an amount of transmission data for which an acknowledgement has not been received and a value related to a round-trip delay time, calculates an estimated reception rate based on an amount of transmission data for which an acknowledgement has been received, and determines that congestion has occurred in the network when the expected transmission rate exceeds the estimated reception rate. (Supplementary Item 2) The communications device according to Supplementary Item 1, wherein the value related to the round-trip delay time includes a value equivalent to a round-trip delay time when congestion is not occurring, and wherein the processor calculates the expected transmission rate by dividing the amount of transmission data for which an acknowledgement has not been received by the value related to the round-trip delay time. (Supplementary Item 3) The communications device according to Supplementary Item 1, wherein the pre-processor determines a maximum amount of transmission data that can be transmitted without waiting for an acknowledgement for a priority class of data to be transmitted, and does not transmit data when the amount of transmission data for which an acknowledgement has not been received for the priority class exceeds the maximum amount of transmission data. (Supplementary Item 4) The communication device according to Supplementary Item 3, wherein the processor calculates the maximum transmission data amount as the maximum transmission data amount that can maintain the target value based on a target value of delay to be suppressed and the estimated reception rate when it is determined that congestion has occurred. (Supplementary Item 5) The communication device according to Supplementary Item 1, wherein the processor monitors communication quality and determines a bandwidth limit amount according to the degree of deterioration of the communication quality. (Supplementary Item 6) A processing method executed by a communication device that transmits data to a counterpart device over a network, comprising the steps of: calculating an expected transmission rate expected in a non-congestion state based on the amount of transmission data that has not been acknowledged and a value related to a round-trip delay time; calculating an estimated reception rate based on the amount of transmission data that has been acknowledged; and determining that congestion has occurred in the network when the expected transmission rate exceeds the estimated reception rate. (Supplementary Item 7) A non-transitory storage medium storing a program for causing a computer to function as a processing unit in the communication device according to any one of Supplementary Item 1 to 5.

[0089] Although the present embodiment has been described above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

[0090] REFERENCE SIGNS LIST 100 Communication device 110 Flow buffer 120 Flow / QoS class DB 130 Transmission control unit 140 Transmitting / receiving unit 150 Acknowledgement response processing unit 160 Transmission rate estimation unit 170 Receiving rate estimation unit 180 Transmitting / receiving rate estimation unit 200 Transport control unit 210, 220 NIC 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. A communications device that transmits data to a peer device via a network, comprising: a processing unit that calculates an expected transmission rate expected in a non-congestion state based on the amount of unacknowledged transmitted data and a value related to round-trip delay time; calculates an estimated reception rate based on the amount of acknowledged transmitted data; and determines that congestion has occurred in the network if the expected transmission rate exceeds the estimated reception rate.

2. The communication device of claim 1, wherein the value relating to the round-trip delay time includes a value corresponding to the round-trip delay time when no congestion occurs, and the processing unit calculates the expected transmission rate by dividing the amount of transmission data for which an acknowledgement has not been received by the value relating to the round-trip delay time.

3. The communication device according to claim 1, wherein the processing unit determines the maximum amount of transmission data that can be transmitted without waiting for an acknowledgment for the priority class of the data to be transmitted, and does not transmit data if the amount of transmission data for that priority class for which an acknowledgment has not been received exceeds the maximum amount of transmission data.

4. The communication device of claim 3, wherein the processing unit calculates the maximum transmission data amount as the maximum transmission data amount that can maintain the target value based on the target value of delay to be suppressed and the estimated reception rate when congestion is determined to have occurred.

5. The communication device according to claim 1, wherein the processing unit monitors communication quality and determines the amount of bandwidth limitation depending on the degree of deterioration of the communication quality.

6. A processing method executed by a communication device that transmits data to a remote device via a network, comprising the steps of: calculating an expected transmission rate expected in a non-congestion state based on the amount of transmission data that has not been acknowledged and a value related to round-trip delay time; calculating an estimated reception rate based on the amount of transmission data that has been acknowledged; and determining that congestion has occurred in the network if the expected transmission rate exceeds the estimated reception rate.

7. A program for causing a computer to function as a processing unit in a communication device according to any one of claims 1 to 5.

Images