WO2015022809A1 - 通信装置及び送信帯域制御方法 - Google Patents
通信装置及び送信帯域制御方法 Download PDFInfo
- Publication number
- WO2015022809A1 WO2015022809A1 PCT/JP2014/065670 JP2014065670W WO2015022809A1 WO 2015022809 A1 WO2015022809 A1 WO 2015022809A1 JP 2014065670 W JP2014065670 W JP 2014065670W WO 2015022809 A1 WO2015022809 A1 WO 2015022809A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- bandwidth
- communication
- connection
- band
- transmission
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
Definitions
- the present invention relates to a communication apparatus and a transmission band control method, and more particularly to a communication apparatus and a transmission band control method for controlling a communication band between terminals.
- TCP Transmission Control Protocol-Virtual Private Network
- the transmitting terminal manages a parameter called a congestion window size (data size that can be transmitted without being notified from the receiving terminal), depending on whether there is RTT (Round Trip Time) or discard detection.
- a congestion window size data size that can be transmitted without being notified from the receiving terminal
- RTT Red Trip Time
- discard detection a parameter that can be transmitted without being notified from the receiving terminal
- the congestion window size By determining that the network is congested at the time of discard detection or when the RTT is increased, and reducing the window size, the transmission band is indirectly decreased to avoid network congestion. Further, when there is no discard or when the RTT decreases, it is determined that the network is free, and the window size is increased, thereby indirectly increasing the transmission bandwidth and effectively using the network bandwidth. The larger the RTT, the more difficult it is to increase the window size. When two or more communications having different RTTs share one line, an unfairness may occur in the allocated bandwidth.
- Patent Document 1 There is also a technique for controlling the transmission rate of a relay connection of a
- the present invention secures a communication bandwidth with a small amount of communication and a large amount of communication even when a communication with a large amount of communication and a communication with a small amount of communication share the same communication line. It is an object of the present invention to provide a communication device and a transmission band control method that enable communication to use up the remaining bandwidth and effectively use the line bandwidth.
- a buffer for storing packets transmitted from the first device to the second device via the network for each connection;
- a bandwidth control unit that controls the transmission bandwidth of each connection according to the control bandwidth of each connection to be set,
- the bandwidth control unit is provided with a communication device that limits the upper limit of the control bandwidth for each connection based on an accumulation amount of packets of each connection accumulated in the buffer and a communication delay time of each connection.
- a buffer for storing packets transmitted from the first device to the second device via the network for each connection With a bandwidth controller, The bandwidth control unit Limit the upper limit bandwidth of each connection based on the number of connections in which the data size of the packet stored in the buffer is equal to or greater than a predetermined threshold, or The transmission bandwidth related to packets transmitted from the first device to the second device via the network is managed for each predetermined interval, and the transmission bandwidth of the interval is based on the number of connections equal to or greater than a predetermined threshold.
- a communication device that limits the upper limit bandwidth of each connection is provided.
- a communication band with a large amount of communication remains in the remaining band while securing a band of communication with a small amount of communication. It is possible to use up all of the bandwidth and effectively use the line bandwidth.
- the system block diagram which has the apparatus in this Embodiment.
- Packet format diagram The format diagram of a state table. The conceptual diagram explaining the meaning of the value which a state table hold
- FIG. 6 is a high-level (conceptual) flowchart for updating a control band.
- band The detailed flowchart figure which updates a control zone
- Example 1 describes a basic form.
- FIG. 1 shows a configuration diagram of a relay system to which the communication apparatus of the present embodiment is applied.
- Communication devices also referred to as relay devices, hereinafter simply referred to as devices
- the apparatuses 200A to 200C and the WAN 140 are connected by access lines 191, 192, and 193.
- a plurality of terminals 111 to 113, 121 to 123, and 131 to 133 are connected to the LANs 110, 120, and 130 at each site.
- the number of terminals, devices, and networks may be an appropriate number other than illustrated.
- FIG. 1 shows a configuration diagram of a relay system to which the communication apparatus of the present embodiment is applied.
- Communication devices also referred to as relay devices, hereinafter simply referred to as devices
- 200A to 200C are installed on communication lines that connect LANs 110, 120, and 130 and WAN 140 in a plurality of bases.
- the apparatuses 200A to 200C and the WAN 140 are connected by access lines 191, 192, and 193.
- FIG. 3 is an explanatory diagram of band division when communication with a large amount of communication and communication with a small amount of communication share the same line.
- the terminals 111 and 112 communicate via the device 200A.
- the communication amount from the terminal 111 to the WAN 140 is large and the communication amount from the terminal 112 to the WAN 140 is small
- the communication of the terminal 111 having a large communication amount and the communication of the terminal 112 having a small communication amount are performed on the access line 191. Will share.
- the device 200A allocates a half of the maximum bandwidth 300 to each communication, the communication of the terminal 111 having a large communication amount can use all the allocated bandwidth 302, while the communication of the terminal 112 having a small communication amount.
- the bandwidth allocated for communication cannot be used up (301), and many unused bandwidths 303 are generated, and the bandwidth cannot be used effectively.
- the present invention relates to transmission band control in apparatuses 200A to 200C. Even when communication with a large amount of communication and communication with a small amount of communication share the same communication line, the bandwidth of the communication with a small amount of communication is reduced. The purpose is to enable the communication with a large amount of communication to use up the remaining bandwidth while securing the bandwidth, and to effectively use the bandwidth.
- FIG. 2 shows a block diagram of apparatuses 200A to 200C of the present embodiment.
- the apparatus 200 includes, for example, a WAN-side and LAN-side network interface (201/2111) that transmits / receives packets to / from an external WAN / LAN network, a TCP packet that is not targeted for acceleration, a UDP packet other than TCP, and an ARP packet.
- a TCP processing unit 1000 that performs control for TCP communication on the WAN side
- a TCP processing unit 1100 that performs control for TCP communication on the LAN side
- the WAN side N transmission buffers 511 and N reception buffers 501 managed by the TCP processing unit 1000, N transmission buffers 510 and N reception buffers 500 managed by the TCP processing unit 1100 on the LAN side, and transmission / reception buffers Proxy 900 for transferring data between them and N entries
- a state table (state storage region) 700 having a, with an external terminal 240 includes an interface 230 for exchanging information such as the contents of the state table 700.
- the above-mentioned N pieces may be different numbers.
- the transmission buffer and the reception buffer accumulate packets between terminals for each connection.
- the TCP processing units 1000 and 1100 and the proxy 900 will be described in detail later and will be outlined here.
- the LAN-side TCP processing unit 1100 includes a transmission history update unit 1105, a packet retransmission unit 1104, a reception history update unit 1106, a distribution unit 1108, and an aggregation unit 1113.
- the reception history update unit 1106 accumulates the received packet data in the LAN side reception buffer 500. Further, the reception history update unit 1106 updates the information of the buffer management pointers (709 to 711) in the state table 700 according to the accumulated data. Further, the reception history update unit 1106 returns an ACK packet describing the position of the received data via the aggregation unit 1113.
- the packet retransmission unit 1104 retransmits the packet according to the ACK number of the received ACK packet and updates the information of the buffer management pointers (715 to 717) in the state table 700.
- the transmission history update unit 1105 transmits the transmission data read from the LAN-side transmission buffer 510 as a packet, and updates the information of the buffer management pointers (715 to 717) in the state table 700 according to the read data.
- the WAN TCP processing unit 1000 includes a transmission bandwidth control unit 1015, a transmission history update unit 1005, a packet retransmission unit 1004, a reception history update unit 1006, a distribution unit 1016, and an aggregation unit 1012.
- the reception history update unit 1006 accumulates the received packet data in the WAN reception buffer 501.
- the reception history update unit 1006 updates the information of the buffer management pointers (722 to 724) in the state table 700 according to the accumulated data. Further, the reception history update unit 1006 returns an ACK packet describing the position of the received data via the aggregation unit 1012. The packet retransmission unit 1004 retransmits the packet according to the ACK number of the received ACK packet and updates the information of the buffer management pointers (728 to 730) in the state table 700.
- the transmission band control unit 1015 accumulates information on the transmission band, the retransmission band, and the number of received ACKs in the state table 700.
- the transmission history update unit 1005 transmits the transmission data read from the WAN side transmission buffer 511 as a packet, and updates the information of the buffer management pointers (728 to 730) in the state table 700 according to the read transmission data size.
- the proxy 900 includes a data reading unit (901, 906), a data processing unit (902, 905), and a data writing unit (903, 904).
- the data reading units (901, 906) update the information of the buffer management pointers (709 to 711, 722 to 724) of the state table 700 according to the data size read from the reception buffer (500, 501).
- the data writing units (903, 904) update the information of the buffer management pointers (715 to 717, 728 to 730) in the state table 700 according to the data size written to the transmission buffers (510, 511).
- FIG. 5 is an explanatory diagram of pointers for transmission / reception buffer management.
- the reception buffers 500 and 501 include a pointer right_recv (711 and 724) indicating the head of the received data, a pointer left_recv (710 and 723) indicating a boundary between the aligned data and the unaligned data, and the proxy 900 has already been read. It manages left_rbuf (709, 722) indicating the boundary between data and data that has not yet been read.
- the pointer right_recv (711, 724) indicating the head of the received data has no loss, and when data is received in order from the front, it increases by the received data size and moves to the right.
- a pointer left_recv (710) indicating the boundary between the aligned data and the unaligned data , 723) moves to the left end of the smallest loss segment.
- the proxy 900 sequentially reads data from the left_rbuf (709, 722) indicating the boundary between the read data and the unread data in the right direction, and moves the left_rbuf (709, 722) to the right by the read data size.
- the maximum data size that can be read is the difference between left_recv (710, 723) and left_rbuf (709, 722).
- the transmission buffers 510 and 511 include a pointer right_sbuf (717, 730) indicating the head of data that has been written by the proxy 900 and can be transmitted, and a pointer right_send (716, indicating the head of data that has already been transmitted). 729) and a pointer left_send (715, 728) indicating the head of data for which an acknowledgment has been received from the receiving side.
- the pointer right_sbuf (717, 730) indicating the head of data that has been written and can be transmitted by the proxy 900 increases by the written data size each time the proxy 900 writes data, and moves to the right. .
- New data is transmitted to the right starting from the pointer right_send (716, 729) indicating the head of the transmitted data, and the right_send (716, 729) increases by the transmitted data size and moves to the right.
- right_send (716, 729) increases by the transmitted data size and moves to the right.
- FIG. 6 shows a format diagram of a packet transmitted and received by the apparatus.
- the packet includes a MAC header 600, an IP header 610, a TCP header 620, a TCP option header 630, and a payload 650.
- the MAC header 600 includes a DMAC 601 that represents a destination MAC address, an SMAC 602 that represents a source MAC address, and a Type 603 that represents a MAC frame type.
- the IP header 610 includes an IP length 611 representing the packet length excluding the MAC header, a protocol 612 representing the protocol number, a SIP 613 representing the transmission source IP address, and a DIP 614 representing the destination IP address.
- the TCP header 620 includes a src. port 621 and dst.
- the TCP option header 630 includes an option kind 631 representing an option type, an option length 632 representing an option length, and left_edge_1 to 4 (633, 633, 633, 633, 633, 633, 633, and 633). 635, 637, 639), right_edge_1 to 4 (634, 636, 638, 640).
- left_edge_1 to 4 (633, 635, 637, 639) and right_edge_1 to 4 (634, 636, 638, 640) are used to notify the positions of data portions that could not be received partially.
- the TCP option header 630 may be used for information exchange between devices when starting TCP communication.
- the MSS Maximum Segment Size
- the SACK Selective Acknowledgments
- the time stamp option is used to notify the opposite device of the reception time of its own device during communication.
- the TCP option is used to transmit functions and information that can be supported by the own apparatus to the opposite apparatus at the start of communication and during communication.
- FIG. 7 shows a format diagram of the status table 700.
- the state table 700 of the apparatus 200 represents, for example, n entries 701 for recording the state of each TCP connection, connect_num 765 indicating the number of connections established for communication, and the number of connections that are actually transmitting data.
- TCP-way-handshake-completed communication is regarded as a connection in which communication is established.
- the upper limit band may be determined for each opposing base (opposite device), and may have a different value for each of the plurality of opposing bases 1 to n as max_speed1 to n (767-1 to n).
- FIG. 18 shows an example of a state table 700-2 having upper limit bands max_speed1 to n (767-1 to n) for each opposing device. In this case, the upper limit band max_speed 767 of the opposite device corresponding to the corresponding connection is used for the calculations shown in FIGS.
- Each entry 701 includes, for example, a VLD 702 that describes whether or not the entry is in use, a connect_state 703 that describes whether or not a LAN or WAN connection is being established, and the IP address of the terminal on the LAN side.
- LIP 704 representing, WIP 705 representing the IP address of the terminal on the WAN side, Lport 706 representing the TCP port number of the terminal on the LAN side, Wport 707 representing the TCP port number of the terminal on the WAN side, and the state of TCP communication on the LAN side
- Lan_state 708 representing a LAN side receive buffer management pointer, lan_left_rbuf 709, lan_left_recv 710, lan_right_recv 711 representing a LAN side window buffer option value, and lan_ representing a LAN side window scale option value s712, lan_rtt 713 representing the average RTT on the LAN side, lan_wan 714 representing the size of data being read from the reception buffer
- FIG. 9 shows a block diagram of proxy 900.
- the proxy 900 includes a data reading unit 901 that reads data from the reception buffer rubuf 500 on the LAN side, and a data processing unit 902 that processes the read data such as compression, decompression, encryption, decryption, deletion, duplication, and appending.
- a data writing unit 903 that writes processed data to the WAN-side transmission buffer sbuf511, a data reading unit 906 that reads data from the WAN-side reception buffer rbuf501, and compression / decompression / encryption / decryption of the read data
- a data processing unit 905 that performs processing such as deletion, duplication, and appending, and a data writing unit 904 that writes processed data to the transmission buffer sbuf 510 on the LAN side.
- Data may be exchanged between the data processing unit 902 and the data processing unit 905.
- the data processing may be other than the above example.
- the data reading unit 901 estimates the data size to be read and the data size after data processing from the top data read from the aligned data accumulated between lan_left_rbuf 709 and lan_left_recv 710.
- a TLS (Transport Layer Security) / SSL (Secure Socket Layer) header, an SMB (Server Message Block) header, or the like may be used as the top data.
- TLS / SSL header the plaintext data size excluding the checksum and header after decryption can be estimated.
- SMB header it is possible to estimate the command data size after creating a new command, prefetching an additional command, or the like.
- the estimated processed data size is added to the difference between wan_right_sbuf 730 and wan_left_send 728, that is, the total value of untransmitted data and ACK confirmation waiting data, if the WAN transmission buffer size wan_sbuf_size is not exceeded, the data is read. And transferred to the data processing unit 902. Further, the larger one of the estimated data size to be read and the data size after data processing is described in lan_wan 714 of the state table 700.
- Another data reading unit 906 estimates the data size to be read and the data size after data processing from the top data read from the aligned data accumulated from wan_left_rbuf 722 to wan_left_recv 723.
- a TLS (Transport Layer Security) / SSL (Secure Socket Layer) header, an SMB (Server Message Block) header, or the like may be used.
- SSL Transaction Layer Security
- SMB Server Message Block
- the estimated processed data size is added to the difference between lan_right_sbuf 717 and lan_left_send 715, that is, the total value of untransmitted data and ACK confirmation wait data, if the transmission buffer size lan_sbuf_size on the LAN side does not exceed, the data is read. And transferred to the data processing unit 905. Furthermore, the larger one of the estimated data size to be read and the data size after data processing is described in wan_lan 727 of the state table 700.
- FIG. 10 shows a block diagram of the TCP processing unit 1000 on the WAN side.
- a TCP processing unit 1000 that realizes TCP communication includes an RX unit (reception unit) 1002 that performs reception processing and a TX unit (transmission unit) 1001 that performs transmission processing.
- the RX unit 1002 is based on a packet distribution unit 1016 that separates a received packet into a TCP control packet with a flag such as SYN or FIN, a packet with data, and an ACK packet, and a flag number described in the TCP control packet.
- the buffer management pointer in the state table 700 is set. It has a reception history update unit 1006 that changes and sends back an ACK packet.
- the TX unit 1001 changes the buffer management pointer in the state table 700 based on the TCP control unit 1003 that transmits the TCP control packet using the TCP state lan_state 708 and wan_state 721 in the state table 700, and the received ACK packet.
- a packet retransmission unit 1004 for notifying the transmission bandwidth control unit 1015 of the retransmission bit length and the number of received ACKs, and a packet carrying data read from the transmission buffer sbuf 511 are transmitted, and the status table 00, the buffer management pointer in 00 is changed, the transmission history update unit 1005 that notifies the transmission bandwidth control unit 1015 of the transmission bit length, the retransmission packet and the data packet are received, and the buffers 1 to n (1009-1 to n) are received.
- the allocating unit 1008, the timer 1013 that generates the current time and notifies the transmission band control unit 1015, and the interval time (predetermined fixed value or measured average RTT) are stored and the transmission band control unit 1015 is stored.
- FIG. 11 is a block diagram of the TCP processing unit 1100 on the LAN side.
- a TCP processing unit 1100 that realizes TCP communication includes an RX unit (reception unit) 1102 that performs reception processing and a TX unit (transmission unit) 1101 that performs transmission processing.
- An RX unit (reception unit) 1102 that performs reception processing includes a packet distribution unit 1108 that separates a received packet from the filter 202 into a TCP control packet, a data-added packet, and an ACK packet, and a status table based on the received TCP control packet Based on the TCP control unit 1107 that changes the TCP states lan_state 708 and wan_state 721 in the 700, and the transmission sequence number SEQ 623 and the reception sequence number ACK 624 of the received data packet, the buffer management pointer in the state table 700 is changed and the ACK packet is changed. And a reception history update unit 1106 for accumulating the data packet data in the reception buffer rubuf500.
- a TX unit (transmission unit) 1101 that performs transmission processing uses a TCP control unit 1103 that transmits a TCP control packet by using the TCP state lan_state 708 and wan_state 721 in the state table 700, and in the state table 700 based on the received ACK packet. From the transmission buffer sbuf510 using the partial acknowledgments left_edge_1 to 4 (633, 635, 636, 639) and right_edge_1 to 4 (634, 636, 638, 640) described in the received ACK packet.
- a packet retransmission unit 1104 that reads data and retransmits the packet, and transmits a packet with the data read from the transmission buffer sbuf 510 to change the buffer management pointer in the state table 700
- a gravel updating section 1105 ACK packet, TCP control packet, the retransmission packet, the aggregate data packet in FIFO, the multiplexer 1113 and the buffer 1109 to 1112 output.
- the transmission bandwidth control unit 1015 of the WAN-side TCP processing unit 1000 manages, in the state table 700, renewed_time 752 indicating the latest update time when the control bandwidth is updated and old_renewed_time 755 indicating the last update time when the control bandwidth is updated. is doing.
- the interval time is added to the latest update time renewed_time 752 to obtain a new latest update time renewed_time 752.
- the most recent update time renewed_time 752 before the addition is old_renewed_time 755 representing the last update time. That is, the latest update time renewed_time 752 used immediately before the latest update time renewed_time 752 becomes old_renewed_time 755 representing the last update time.
- a measured average RTT or initial RTT may be used, or a fixed value may be used.
- the flow of a packet in the apparatus 200 when a packet with data is received from the LAN side will be described with reference to FIG.
- the packet with data arriving from the LAN side enters the LAN side TCP processing unit 1100 and arrives at the reception history update unit 1106.
- the reception history update unit 1106 returns the ACK packet to the LAN side via the aggregation unit 1113 and accumulates the data described in the packet in the LAN side reception buffer rbuf500. Further, the pointer of the status table 700 is updated based on the accumulated data size.
- the data reading unit 901 reads the aligned data stored in the LAN side reception buffer rubuf 500 and transfers it to the data processing unit 902. Further, the pointer of the state table 700 is updated based on the read data size.
- the data processing unit 902 processes the data and transfers it to the data writing unit 903. Furthermore, the data size being processed in the state table 700 is updated based on the data size being processed.
- the data writing unit 903 writes the processed data to the WAN side transmission buffer sbuf511. Further, the pointer of the state table 700 is updated based on the written data size.
- the data written in the WAN side transmission buffer sbuf 511 is read from the transmission history update unit 1005 of the WAN side TCP processing unit 1000 and transmitted to the WAN side as a packet with data.
- the reception history update unit 1106 will be further described.
- the remaining amount of the reception buffer is calculated by subtracting the difference between lan_right_recv 711 and lan_left_rbuf 709 from the maximum value of the reception buffer on the LAN side.
- the size of the payload 650 is equal to or smaller than the remaining amount of the reception buffer, all the data described in the payload 650 is stored in the reception buffer.
- the size of the payload 650 is larger than the remaining amount of the reception buffer, only data having a size corresponding to the remaining amount of the reception buffer from the beginning of the payload 650 is stored in the reception buffer.
- the reception buffer management pointer is updated based on the value of SEQ 623 described in the TCP header 620 of the packet with data and the stored data size.
- lan_right_recv711 is changed to the value obtained by adding the stored data size to SEQ623.
- the received data is described in the reception buffer on the LAN side so that the end of the received data is lan_right_recv711.
- an ACK packet in which one reception buffer management pointer lan_left_recv 710 is written in ACK 624 of the TCP header 620 is returned to the LAN side.
- the transmission history update unit 1005 will be further described.
- wan_right_send 729 Data from wan_right_send 729 to the maximum wan_right_sbuf 730 is read from the WAN side transmission buffer sbuf 511 in the right direction. wan_right_send 729 increases by the read data size and moves to the right. Further, the read data is described in the payload 650, and a packet with data to which the TCP header 620 in which wan_right_send 729 is described in SEQ623 is added is transmitted to the WAN side.
- the transmission bandwidth control unit 1015 controls the transmission bandwidth of data going out to the WAN side of each TCP communication using the variables managed by the state table 700.
- the variables of the status table 700 managed by the transmission bandwidth control unit 1015 will be described.
- the state table 700 includes, for each connection, renewed_time 752 indicating the latest update time when the control band is updated, old_renewed_time 755 indicating the last update time when the control band is updated, and transmission byte integration from the latest update time renewed_time 752 to the current time.
- a control band token 738 after the latest update time renewed_time 752 represents a control band at the current time (in this embodiment, it is expressed as token or token).
- the transmission band after the latest update time renewed_time 752 represents the transmission band at the current time (in this embodiment, represented as snd), and the transmission bit integrated value after the latest update time renewed_time 752 is the current time and the latest update time renewed_time 752. It is obtained by dividing by the difference of.
- the retransmission band after the latest update time renewed_time 752 represents the retransmission band at the current time (in this embodiment, expressed as rts), and the retransmission bit integration value after the latest update time renewed_time 752 is the current time and the latest update time renewed_time 752.
- the reception band after the latest update time renewed_time 752 represents the reception band at the current time (in this embodiment, expressed as rcv), and is a value obtained by adding the WAN side MSS and 8 to the number of ACK receptions after the most recent update time renewed_time 752. Is divided by the difference between the current time current_time and the latest update time renewed_time 752.
- the control bandwidth / transmission bandwidth / reception bandwidth / retransmission bandwidth before the latest update time renewed_time 752 represents the average value of the control bandwidth / transmission bandwidth / reception bandwidth / retransmission bandwidth from the update time old_renewed_time 755 to the latest update time renewed_time 752 ( In this embodiment, it is expressed as old_token, old_snd, old_rcv, old_rts).
- the control band / transmission band of the previous update time old_renewed_time 755 represents the control band / transmission band immediately before the previous update time old_renewed_time 755 (in the present embodiment, it is represented as old_old_token, old_old_snd).
- the retransmission rate / discard rate old_loss_ratio before the latest update time renewed_time 752 is obtained by old_rts / old_old_snd or 1-old_rcv / old_old_snd. Further, the retransmission rate / discard rate loss_ratio at the current time after the latest update time renewed_time 752 is obtained by rts / old_snd or 1-rcv / old_snd.
- a fixed value may be used as the interval time, or wan_rtt 726 described in the state table 700 may be used.
- FIG. 8 shows the relationship between the last update time old_renewed_time 755, the latest update time renewed_time 752, the current time, and the control band token, transmission band snd, reception band rcv, retransmission band rts, retransmission rate / discard rate loss_ratio before and after that. .
- the difference between the latest update time renewed_time 752 and the previous update time old_renewed_time 755 is the interval time.
- the average values of the control band and the transmission band of the interval time before the update time old_renewed_time 755 two times before are expressed as old_old_token and old_old_snd (801).
- the average values of the control bandwidth, transmission bandwidth, reception bandwidth, retransmission bandwidth, retransmission rate / discard rate between the last update time old_renewed_time 755 and the latest update time renewed_time 752 are represented by old_token, old_snd, old_rcv, old_rts, old_loss_ratio 80 ).
- the average value of the control band / transmission band / reception band / retransmission band / retransmission rate / discard rate from the latest update time renewed_time 752 to the current time current_time is expressed as token, snd, rcv, rts, and loss_ratio (801).
- the transmission bandwidth control unit 1015 calculates the discard rate / retransmission rate (loss_ratio753 and old_loss_ratio754) using the above-described values described in the state table 700.
- the discard rate / retransmission rate loss_ratio 753 of the current time current_time is calculated as rts / old_token, rts / old_snd, 1-rcv / old_token, or 1-rcv / old_snd.
- the discard rate / retransmission rate old_loss_ratio 754 at the latest update time is calculated by old_rts / old_old_token or old_rts / old_old_snd or 1-old_rcv / old_old_token or 1-old_rcv / old_old_snd. Further, based on the change in the discard rate / retransmission rate (the ratio of old_loss_ratio 754 and loss_ratio 753), the control band (token or token) is determined and transmitted to the token update unit 1017. Further, the state table 700 is updated. Details of the method of updating the control band (token or token) will be described later with reference to FIGS.
- the token update unit 1017 manages the token bucket for each TCP connection based on the value of the control band (token or token) transmitted from the transmission band control unit 1015, and notifies the multiplexer 1012 of a connection that can be transmitted.
- FIG. 12 is a graph showing time transitions of the transmission band 1201, the discard rate 1202, and the discard rate change rate 1203 on the transmission side of a device performing communication using the original TCP.
- FIG. 12 is a graph showing time transitions of the transmission band 1201, the discard rate 1202, and the discard rate change rate 1203 on the transmission side of a device performing communication using the original TCP.
- communication using unique TCP is used as an example.
- the present invention is not limited to the example described below, and an appropriate protocol modified based on TCP communication and TCP communication may be applied. There are roughly three phases in increasing / decreasing the transmission bandwidth of communication using the original TCP.
- Phase 1 is a step of increasing the transmission band
- Phase 2 is a step of decreasing the transmission band
- Phase 3 is a step of making the transmission band constant.
- the transmission bandwidth increases in phase 1 (1204), and at some point exceeds the bottleneck bandwidth (1213).
- the transmission bandwidth exceeds the bottleneck bandwidth
- packet discarding occurs, but it takes RTT or more until the discard location is notified from the reception side to the transmission side (1215). Therefore, when the transmission band exceeds the bottleneck band, the increase in the discard rate appears after RTT (1214).
- the discard rate is obtained by dividing the most recent retransmission band by the transmission band before RTT. While the transmission band is smaller than the bottleneck band, only the stochastic discard due to contention with other traffic occurs, so the discard rate is almost constant (1210).
- discard due to overuse (1211) is added in addition to stochastic discard, and the discard rate starts to increase (1212).
- the change rate of the discard rate increases rapidly from 1 and exceeds the threshold value k (1209).
- the rate of change of the discard rate increases rapidly and exceeds the threshold value k, it is determined that congestion has occurred in the network. If it is determined that congestion has occurred in the network, a value obtained by subtracting the current retransmission bandwidth from the transmission bandwidth before RTT is set as a new transmission bandwidth (1218). The reason why the new transmission band is calculated using the transmission band before RTT is that the time when the transmission band exceeds the bottleneck band is more than RTT. Since the increase in the discard rate continues for a while (1212), the transmission band continues to decrease during that time. The step of reducing the transmission band is phase 2 (1205). When the transmission band decreases and becomes smaller than the bottleneck band, the discard rate starts to decrease (1219).
- the change rate of the discard rate becomes smaller than 1 and falls below the threshold value k (1220)
- the step of making the transmission band constant is phase 3 (1206). If the number of data parts that have been confirmed to be received has increased compared to before RTT, it is determined that the retransmission processing of the discarded packet has been completed, and the transmission band is increased again (phase 1).
- the transmission band is increased slowly, for example, linearly (1207). If no congestion is detected for a certain period T, then the transmission band is increased rapidly (eg, non-linearly) (1208). When increasing non-linearly, it may be increased exponentially, such as multiplying by ⁇ E every RTT (1216).
- the period T during which the initial transmission band is increased slowly may be determined by the RTT and the token (token: control band), or may be proportional to the product of these (1221).
- the transmission band may be increased linearly at a rate proportional to MSS / RTT for each RTT.
- the proportionality coefficient ⁇ L when increasing linearly at a rate proportional to MSS / RTT for each RTT may be set to a value smaller than 1 (1217).
- the transmission bandwidth control method described above network congestion is not detected, and the transmission bandwidth of the TCP communication is linearly set for a certain period after the data portion whose reception has been confirmed is being updated.
- a communication device that increases the transmission band in a non-linear manner is realized.
- a communication device that detects network congestion, and the past history of the transmission band, the retransmission band, and the number of received ACKs, the discard rate or the retransmission rate and their changes A communication apparatus that estimates the rate and a communication apparatus that reduces the transmission band using the past history of the transmission band, the retransmission band, and the number of received ACKs when congestion is detected are realized.
- the transmission bandwidth is increased (for example, linearly) than normal TCP communication for a certain period after network congestion is not detected and the data location that has been confirmed to be received is being updated.
- the transmission bandwidth is rapidly increased (for example, exponentially) so that when there is no competition with normal TCP communication, the transmission bandwidth reaches the bottleneck bandwidth and reaches the top speed. Time can be shortened.
- the transmission bandwidth can be continuously increased until the transmission bandwidth reaches the bottleneck bandwidth and reaches the top speed without being affected by the probabilistic discard, and the line bandwidth can be used up.
- the band can be reduced according to the scale of congestion by reducing the band using the past transmission band and the current retransmission band.
- FIGS. 13 to 17 are flowcharts for explaining details of a method by which the transmission bandwidth control unit 1015 updates the control bandwidth (token or token).
- FIGS. 13 to 15 show details of bandwidth control in the unique TCP
- FIGS. 16 to 17 show details of a method for dividing the maximum bandwidth in accordance with the communication amount in communication using the unique TCP.
- FIG. 13 shows a conceptual flowchart when the transmission band control unit 1015 updates the control band (token or token).
- the transmission bandwidth control unit 1015 executes processing according to this flowchart, thereby realizing bandwidth control based on the retransmission rate, and can use up the line bandwidth without depending on the RTT and the discard rate.
- Each step in FIG. 13 is executed by the transmission band control unit 1015.
- the control band update process starts (step 1301), it is determined whether or not the number of confirmed ACKs has increased for a certain period (step 1302). If the number of confirmed ACKs has increased for a certain period, it is determined that retransmission has failed, and the control band is made constant according to the number of received ACKs (step 1306).
- the control band token 738 is set as the reception band rcv750.
- step 1303 It is determined whether or not the threshold value is exceeded (step 1303).
- the increase rate of the packet retransmission rate exceeds a predetermined threshold
- the current retransmission band (rts) and the past control band (old_token 739) or the past (before the reference time)
- the control band (token 738) is updated using the transmission band (old_snd 746) (step 1304).
- the control band in the past before the latest update time renewed_time 752 is reduced by an amount corresponding to the current retransmission band to obtain the control band at the current time.
- the increase rate of the packet retransmission rate does not exceed a predetermined threshold in step 1303, the control band is increased (step 1305).
- control band (token 738) is updated based on the minimum band (min_token 741) of each connection (step 1307). Further, the control band token is updated based on the weight weight 764 of each connection (step 1308). A method for calculating the weight of each connection weight 764 will be described later.
- the transmission bandwidth can be continuously increased until the transmission bandwidth reaches the bottleneck bandwidth and reaches the top speed without being affected by the probabilistic discard, and the line bandwidth can be used up. Furthermore, when it is determined that the band is discarded due to excessive use of the band, the band can be reduced according to the scale of congestion by reducing the band using the past transmission band and the current retransmission band.
- FIG. 14 shows a detailed flowchart of step 1305 when the transmission bandwidth control unit 1015 increases the control bandwidth (token 738 or token). It is determined whether or not the difference between the current time current_time and the inc_time 744 representing the most recent time at which the control
- FIG. 15 shows a detailed flowchart when the transmission band control unit 1015 updates the control band (token 738 or token).
- FIG. 15 partially corresponds to the processing of FIG.
- Each step is executed by the transmission band control unit 1015.
- the transmission bandwidth control unit 1015 executes processing according to this flowchart, thereby realizing bandwidth control based on the retransmission rate, and can use up the line bandwidth without depending on the RTT and the discard rate.
- update processing of the control band (token) starts (step 1501)
- the transmission band control unit 1015 stores the difference between the current time current_time output from the timer 1013 and the latest update time renewed_time 752 described in the state table 700 as an interval storage.
- step 1502 It is determined whether or not the interval time output by the unit 1014 is longer than the interval time (step 1502). As the interval time, wan_rtt 726 of the state table 700 in which the average value or initial value of the measured RTT is recorded may be used. If it is determined to be true in step 1502, the value of the current control band token after the latest update time renewed_time 752 is saved in tmp (step 1503). Further, it is determined whether or not the number of confirmed ACKs has increased in a certain period. Specifically, it is determined whether or not the ACK confirmed location wan_left_send is larger than the ACK confirmed location old_wan_left_send 734 at the latest update time renewed_time 752 (step 1504).
- the discard rate loss_ratio 753 at the current time current_time obtained by dividing by the old_token 739 is the retransmission band from the last update time old_renewed_time 755 to the latest update time renewed_time 752 or the discard band old_rtw7_new_old5 ld_snd747 or K times the old retransmission ratio old_loss_ratio754 as of the most recent update time renewed_time752 obtained by dividing the control band Old_old_token740: determines greater or not than (K advance one or more coefficients determined) (Step 1505).
- step 1506 If the increase rate of the packet retransmission rate exceeds the threshold value, it is determined that congestion has occurred in the network, and the control bandwidth token 738 is decreased (step 1506).
- a value obtained by subtracting the retransmission band rts748 from the latest update time renewed_time 752 to the current time from the control band old_token 739 from the last update time old_renewed_time 755 to the latest update time renewed_time 752 is set as a new control band token 738.
- t_token 742 representing the latest control band in which congestion is not detected is overwritten with the new control band token 738
- inc_time 744 representing the latest time when the control band is started to be increased is overwritten with the current time current_time.
- control band token 738 is the reception band rcv 750 from the latest update time renewed_time 752 to the current time current_time. Further, t_token 742 representing the latest control band in which congestion is not detected is overwritten with the new control band token 738, and inc_time 744 representing the latest time when the control band is started to be increased is overwritten with the current time current_time.
- t_token 742 representing the latest control band in which congestion is not detected is overwritten with the new control band token 738
- inc_time 744 representing the latest time when the control band is started to be increased is overwritten with the current time current_time.
- the pointer wan_left_send 728 indicating the end of the ACK confirmed data is increased from the pointer old_wan_left_send 734 indicating the end of the ACK confirmed data at the last update time renewed_time 752, and It is determined whether the packet discard rate and the rate of change of the retransmission rate (loss_ratio753 / old_loss_ratio754) exceed a predetermined threshold K759 (step 1510).
- the value of K may be fixed or may vary depending on the value of token.
- step 1510 If it is determined to be true in step 1510, it is determined that the network is congested, and a new control band is set so as to be smaller than the value of the control band old_token 739 at the last update time renewed_time 752, as in step 1506.
- the value of token 738 is determined (step 1511). For example, the retransmission / discard bandwidth rts748 is used to reduce the bandwidth.
- the new control band token 738 the control band old_token 739 at the previous update time renewed_time 752—the retransmission band or the discard band rts748, etc. (step 1511). If it is determined to be false in step 1510, nothing is done.
- step 1512 when the control band token 738 is smaller than the minimum guaranteed band min_token 741 of each TCP communication, the control band token 738 is changed to the minimum guaranteed band min_token 741 of each TCP communication (step 1512). That is, the smaller of the tokens determined by the two expressions shown in step 1512 of FIG. Note that data such as token 738 and min_token 741 in step 1512 can be read with reference to the state table 700. After this step, the process proceeds to step 1513.
- step 1513 when the control bandwidth token 738 is larger than the maximum bandwidth max_token 770 determined by the traffic weight weight 764 of each TCP communication, the control bandwidth token 738 is changed to the maximum bandwidth max_token 770 (step 1513).
- the maximum bandwidth max_token 770 determined by the traffic weight weight 764 is determined by a flowchart described later.
- FIG. 16 shows a flowchart for the transmission bandwidth control unit 1015 to calculate the traffic weight weight 764 of each TCP communication. This flowchart is executed at an appropriate timing before step S1513 in FIG.
- the transmission bandwidth control unit 1015 is the bit amount of data accumulated in the reception buffer on the LAN side and the transmission buffer on the WAN side (wan_right_sbuf730-wan_left_send728 + lan_right1-rec71).
- the transmission bandwidth control unit 1015 determines whether or not the traffic weight weight 764 is greater than the value obtained by dividing max_speed 767, which is the maximum bandwidth of the device 200, by active_snd_num 766 representing the number of connections that are actually transmitting data. (Step 1602). Note that the amount of bytes of data accumulated in the LAN side reception buffer and the WAN side transmission buffer (wan_right_sbuf730-wan_left_send728 + lan_right_recv711-lan_left_rbuf709) is a value greater than or equal to a certain value, or the current bandwidth current_dn45 is a value equal to or greater than the current value current_n7. It is regarded as a connection that is actually transmitting data.
- the transmission bandwidth control unit 1015 substitutes a value obtained by equally dividing the maximum bandwidth max_speed 767 of the device by the number of connections active_snd_num 766 during data transmission into the traffic weight weight 764 (step 1603).
- the traffic weight weight 764 By limiting the traffic weight weight 764 to a bandwidth equal to or less than the bandwidth when fair distribution is performed using the above flowchart, it is possible to prevent a communication with a large traffic from using too much bandwidth.
- FIG. 17 shows a flowchart for the transmission bandwidth control unit 1015 to calculate the maximum bandwidth max_token 770 of each TCP communication using the traffic weight weight 764.
- update processing of the maximum bandwidth (max_token 770) of each TCP communication is started (step 1700)
- a value obtained by equally dividing the maximum bandwidth max_speed 767 of the apparatus 200 by the number of connections active_snd_num 766 during data transmission is the sum ⁇ weight (weight 68) of the traffic weight weight 764.
- the value obtained by multiplying the value divided by the maximum bandwidth max_speed 767 of the device 200 is substituted into the maximum bandwidth max_token 770 of each TCP communication (step 1701).
- the maximum possible value of the traffic weight weight 764 is assigned as the maximum value of each communication. If the total sum ⁇ weight of the traffic weight weight 764 is smaller than the value obtained by equally dividing the maximum bandwidth max_speed 767 of the device 200 by the number of connections active_snd_num 766 during data transmission (step 1702), the maximum bandwidth of the device 200 is limited to communication with a small traffic. Assuming that max_speed 767 cannot be used up, the maximum bandwidth max_token 770 of each TCP communication is set as the maximum bandwidth max_speed 767 of the apparatus 200 (step 1703). In FIG. 4, by changing the control band token 738 according to the flowcharts of FIGS.
- the communication 401 with a small communication amount can use a necessary band without compressing the band with the two communications 402 and 403 with a large communication amount.
- the two communications 402 and 403 having a large communication volume can be used up while equally dividing the remaining band of the communication 401 having a small communication volume.
- the apparatus 200 uses the values such as token 738 and snd 745 in the state table 700 to transmit the time transition of the throughput for each communication as illustrated in FIG. 4 to the external terminal 240 via the interface 230. It may be displayed.
- the maximum bandwidth max_token 770 for each TCP communication is determined using the traffic weight weight 764, and the control bandwidth token 738 is limited to the maximum bandwidth max_token 770 for each TCP communication. While protecting a communication band with a small amount of communication, it is possible to use up a band where a communication with a large amount of communication is left evenly divided.
- control bandwidth (token) increases even in communication (connection) with a small communication amount (FIGS. 12: 1204, 1207, 1208; FIG. 15: 1507).
- the upper limit of this control band is limited in step S1513 in FIG. If FIG. 16 and FIG. 17 are omitted, the maximum bandwidth may be divided by the number of connections, and the state shown in FIG. 3 may be obtained.
- the traffic weight weight increases, so that the maximum control bandwidth max_token of each connection becomes smaller than the conventional one. Therefore, the upper limit of the control band for communication with a small communication volume is limited as compared with the conventional one, and the transmission band is limited.
- the max_token becomes smaller as the amount of buffer stored data for communication with a larger amount of communication becomes larger, and the max_token becomes smaller as the RTT becomes smaller. Therefore, while the minimum bandwidth for communication with a small amount of communication is secured in step 1512, the maximum control bandwidth for communication with a small amount of communication is limited as the amount of data stored in the buffer for communication with a large amount of communication increases or the RTT decreases. As a result, communication with a large amount of communication can use the bandwidth.
- One form of communication device manages the bandwidth related to packets transmitted from the first communication device to the second communication device via the network for each interval, and is based on the number of connections whose interval transmission bandwidth is equal to or greater than a certain value. Limit the upper bandwidth limit of each connection.
- Another form of the communication device includes a buffer for storing packets transmitted from the first communication device to the second communication device via the network for each connection, and the data size of the packets stored in the buffer is a constant value. The upper limit bandwidth of each connection is limited based on the number of connections described above.
- the maximum bandwidth of a packet transmitted from the device may be determined, and the upper limit bandwidth of each connection may be limited based on a value obtained by dividing the maximum bandwidth by the number of connections.
- the upper limit bandwidth of each connection may be limited based on a value obtained by dividing the maximum bandwidth determined for each opposing device by the number of connections.
- the round trip delay time may be measured for each connection, and the upper limit bandwidth of each connection may be limited based on a value obtained by dividing the buffer accumulation amount of each connection by the round trip delay time.
- the transmission bandwidth of each connection may be controlled based on the discard rate measured for each connection and the change thereof.
- the transmission band of each connection may be controlled based on the control band of the past interval measured for each connection and the retransmission band / discard band of the latest interval.
- a communication device that relays a plurality of TCP communications on the LAN side and the WAN side, A bandwidth control unit for controlling the transmission bandwidth of each TCP communication; A reception buffer for storing data received from the LAN side of each TCP communication; A transmission buffer for storing data to be transmitted to the WAN side of each TCP communication; A status table that records a history of data locations that have been confirmed to be received in each TCP communication; A bandwidth table for recording past history of transmission bandwidth, control bandwidth, reception bandwidth, and retransmission bandwidth in each TCP communication; Have The bandwidth controller Based on the past history of the transmission band, control band, reception band, and retransmission band described in the status table, and the history of the data location that has been confirmed to be received in the status table, the presence or absence of TCP communication congestion has been confirmed.
- TCP communication transmission band is increased.
- TCP communication is performed.
- Reduce the transmission bandwidth of The round trip delay time indicates the number of connections where the amount of data accumulated in the transmission buffer and reception buffer exceeds a certain value, or the number of connections where the past transmission bandwidth exceeds a certain value, and the amount of data accumulated in the transmission buffer and reception buffer.
- a communication device is provided that limits the upper limit bandwidth of each connection based on the divided value.
- the present invention can be used for a communication device that relays communication between terminals, for example.
- Communication device 110 120, 130 Network 111, 121, 131 Terminal 191, 192, 193 Line 1000, 1100 Processing unit 1015 Transmission bandwidth control unit 500, 501 Reception buffer 510, 511 Transmission buffer 900 Proxy 700 Status tables 502, 503, 504 Pointer 600 Header data 701 entry
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を公平に使い切ることができるようする。 バッファは、第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積する。帯域制御部1015は、設定される各コネクションの制御帯域に応じて、各コネクションの送信帯域を制御する。帯域制御部1015は、各コネクションについて、バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、制御帯域の上限を制限する。
Description
本発明は、通信装置及び送信帯域制御方法に係り、特に、端末間の通信帯域を制御する通信装置及び送信帯域制御方法に関する。
クラウド等に用いられる拠点間の通信網として、IP-VPN(Internet Protocol- Virtual Private Network)技術等を用いたWAN(Wide Area Network)を用いることが、一般的になっている。 或る拠点に存在する端末が、別の拠点に存在する端末と通信する場合は、自拠点LANとWANを接続する回線と、WANと別拠点LANを接続する回線とを経由して通信が行われる。これらの回線は、契約帯域によって、使用可能な帯域幅が制限されている。
端末間の通信では、TCPを用いるのが一般的である。TCP通信では、送信端末が送信したデータに対して、受信端末が受信済みデータの位置を送信端末にフィードバック通知する。送信端末は、フィードバック通知される受信済みデータの位置が増加しなくなると、廃棄検出と判定する。
さらに、送信端末は、輻輳ウィンドウサイズ(受信したことを受信端末から通知されなくても送信可能なデータサイズ)と呼ばれるパラメータを管理しており、RTT(Round Trip Time)や廃棄検出の有無に応じて、輻輳ウィンドウサイズを変化させる。
廃棄検出時やRTT増加時にネットワークが混雑していると判定して、ウィンドウサイズを減少させることで、送信帯域を間接的に減少させて、ネットワークの混雑を回避する。また、廃棄が無い時やRTT減少時にネットワークが空いていると判定して、ウィンドウサイズを増加させることで、送信帯域を間接的に増加させて、ネットワークの回線帯域を有効利用する。
RTTが大きいほど、ウィンドウサイズが増加しにくくなり、RTTの異なる2つ以上の通信が1つの回線を共有する際に、割り当てられる帯域に不公平が生じる場合がある。 通信装置の中継コネクションの送信レートを、中継中のコネクション数に応じて制御する技術もある(特許文献1)。
端末間の通信では、TCPを用いるのが一般的である。TCP通信では、送信端末が送信したデータに対して、受信端末が受信済みデータの位置を送信端末にフィードバック通知する。送信端末は、フィードバック通知される受信済みデータの位置が増加しなくなると、廃棄検出と判定する。
さらに、送信端末は、輻輳ウィンドウサイズ(受信したことを受信端末から通知されなくても送信可能なデータサイズ)と呼ばれるパラメータを管理しており、RTT(Round Trip Time)や廃棄検出の有無に応じて、輻輳ウィンドウサイズを変化させる。
廃棄検出時やRTT増加時にネットワークが混雑していると判定して、ウィンドウサイズを減少させることで、送信帯域を間接的に減少させて、ネットワークの混雑を回避する。また、廃棄が無い時やRTT減少時にネットワークが空いていると判定して、ウィンドウサイズを増加させることで、送信帯域を間接的に増加させて、ネットワークの回線帯域を有効利用する。
RTTが大きいほど、ウィンドウサイズが増加しにくくなり、RTTの異なる2つ以上の通信が1つの回線を共有する際に、割り当てられる帯域に不公平が生じる場合がある。 通信装置の中継コネクションの送信レートを、中継中のコネクション数に応じて制御する技術もある(特許文献1)。
中継コネクションの送信レートをコネクション数に応じて制御すると、通信量の多寡やRTTが考慮されていないために、通信量の少ない通信が割当てられた帯域を使いきれず、通信量の多い通信が余剰の帯域を使えない課題があった。
本発明は、以上の点に鑑み、通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を使い切ることができるようにし、回線帯域を有効に活用することが可能な通信装置及び送信帯域制御方法を提供することを目的とする。
本発明は、以上の点に鑑み、通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を使い切ることができるようにし、回線帯域を有効に活用することが可能な通信装置及び送信帯域制御方法を提供することを目的とする。
上記課題を解決するために、本願発明の一態様では、
第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するバッファと、
設定される各コネクションの制御帯域に応じて、各コネクションの送信帯域を制御する帯域制御部と
を備え、
前記帯域制御部は、各コネクションについて、前記バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、前記制御帯域の上限を制限する通信装置が提供される。
上述の態様により、通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を使い切ることができるようにし、回線帯域を有効に活用することが可能となる。
また、本願発明の他の一態様では、
第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するステップと、
設定される各コネクションの制御帯域に応じて、各コネクションの送信帯域を制御するステップと
各コネクションについて、前記バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、前記制御帯域の上限値を求めるステップと
を含む送信帯域制御方法が提供される。
本願発明のさらに他の一態様では、
第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するバッファと、
帯域制御部と
を備え、
前記帯域制御部は、
前記バッファに蓄積されたパケットのデータサイズが予め定められた閾値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する、又は、
前記第一の装置からネットワークを介して前記第二の装置に送信されるパケットに関する送信帯域を所定のインターバル毎に管理し、インターバルの送信帯域が予め定められた閾値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する通信装置が提供される。
第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するバッファと、
設定される各コネクションの制御帯域に応じて、各コネクションの送信帯域を制御する帯域制御部と
を備え、
前記帯域制御部は、各コネクションについて、前記バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、前記制御帯域の上限を制限する通信装置が提供される。
上述の態様により、通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を使い切ることができるようにし、回線帯域を有効に活用することが可能となる。
また、本願発明の他の一態様では、
第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するステップと、
設定される各コネクションの制御帯域に応じて、各コネクションの送信帯域を制御するステップと
各コネクションについて、前記バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、前記制御帯域の上限値を求めるステップと
を含む送信帯域制御方法が提供される。
本願発明のさらに他の一態様では、
第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するバッファと、
帯域制御部と
を備え、
前記帯域制御部は、
前記バッファに蓄積されたパケットのデータサイズが予め定められた閾値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する、又は、
前記第一の装置からネットワークを介して前記第二の装置に送信されるパケットに関する送信帯域を所定のインターバル毎に管理し、インターバルの送信帯域が予め定められた閾値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する通信装置が提供される。
本発明によると、通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を使い切ることができるようにし、回線帯域を有効に活用することが可能となる。
本発明を実施するための代表的な形態は、下記の通りである。実施例1には基本的な一形態を、記載する。
まず、図1と図3を用いて、本発明が解決しようとする課題について説明する。
図1には、本実施の形態の通信装置を適用した中継システムの構成図を示す。
通信装置(中継装置ともいう。以下、単に装置と記す)200A~Cは、複数の拠点内のLAN110、120、130とWAN140を接続する通信回線上に設置される。装置200A~CとWAN140は、アクセス回線191、192、193で接続されている。各拠点のLAN110、120、130には、複数の端末111~113、121~123、131~133が接続している。また、端末、装置及びネットワークの数は図示以外にも適宜の数を備えても良い。
図3には、通信量の多い通信と、通信量の少ない通信とが、同一の回線を共有する場合の帯域分割の説明図を示す。
端末111と端末112は、装置200Aを経由して通信を行う。端末111からWAN140に向かう通信の通信量が多く、端末112からWAN140に向かう通信の通信量が少ない場合、通信量の多い端末111の通信と、通信量の少ない端末112の通信が、アクセス回線191を共有することになる。
このような時に、装置200Aが各通信に最大帯域300の半分の帯域を割り当てると、通信量の多い端末111の通信は割り当てられた帯域302を全て使いきれる一方で、通信量の少ない端末112の通信が割り当てられた帯域を使い切ることができず(301)、多くの未使用帯域303を発生させてしまい、帯域を有効に活用できないケースがあった。
本発明は、装置200A~Cにおける送信帯域の制御に関するものであり、通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を使い切ることができるようにし、回線帯域を有効に活用することを目的とする。
図1には、本実施の形態の通信装置を適用した中継システムの構成図を示す。
通信装置(中継装置ともいう。以下、単に装置と記す)200A~Cは、複数の拠点内のLAN110、120、130とWAN140を接続する通信回線上に設置される。装置200A~CとWAN140は、アクセス回線191、192、193で接続されている。各拠点のLAN110、120、130には、複数の端末111~113、121~123、131~133が接続している。また、端末、装置及びネットワークの数は図示以外にも適宜の数を備えても良い。
図3には、通信量の多い通信と、通信量の少ない通信とが、同一の回線を共有する場合の帯域分割の説明図を示す。
端末111と端末112は、装置200Aを経由して通信を行う。端末111からWAN140に向かう通信の通信量が多く、端末112からWAN140に向かう通信の通信量が少ない場合、通信量の多い端末111の通信と、通信量の少ない端末112の通信が、アクセス回線191を共有することになる。
このような時に、装置200Aが各通信に最大帯域300の半分の帯域を割り当てると、通信量の多い端末111の通信は割り当てられた帯域302を全て使いきれる一方で、通信量の少ない端末112の通信が割り当てられた帯域を使い切ることができず(301)、多くの未使用帯域303を発生させてしまい、帯域を有効に活用できないケースがあった。
本発明は、装置200A~Cにおける送信帯域の制御に関するものであり、通信量の多い通信と、通信量の少ない通信が、同一の通信回線を共有する場合でも、通信量の少ない通信の帯域を確保しつつ、通信量の多い通信が残りの帯域を使い切ることができるようにし、回線帯域を有効に活用することを目的とする。
図2には、本実施の形態の装置200A~Cのブロック図を示す。
装置200は、例えば、外部のWAN/LANネットワークとのパケットの送受信を行うWAN側及びLAN側のネットワークインターフェース(201/211)と、高速化非対象のTCPパケットやTCP以外のUDPパケットやARPパケット等を素通しさせるためのフィルタ(202/210)と、WAN側のTCP通信のための制御を行うTCP処理部1000と、LAN側のTCP通信のための制御を行うTCP処理部1100と、WAN側のTCP処理部1000の管理するN個の送信バッファ511およびN個の受信バッファ501と、LAN側のTCP処理部1100の管理するN個の送信バッファ510およびN個の受信バッファ500と、送受信バッファ間でデータの乗せ換えを行うプロキシ900と、N個のエントリを備えた状態テーブル(状態記憶領域)700と、外部の端末240との間で、状態テーブル700の内容などの情報をやり取りするためのインターフェース230とを備える。なお、上述のN個は、それぞれ異なる数でもよい。例えば、送信バッファ、受信バッファは、端末間のパケットをコネクション毎に蓄積する。
TCP処理部1000、1100、プロキシ900については、後に詳述しここでは概略を述べる。
装置200は、例えば、外部のWAN/LANネットワークとのパケットの送受信を行うWAN側及びLAN側のネットワークインターフェース(201/211)と、高速化非対象のTCPパケットやTCP以外のUDPパケットやARPパケット等を素通しさせるためのフィルタ(202/210)と、WAN側のTCP通信のための制御を行うTCP処理部1000と、LAN側のTCP通信のための制御を行うTCP処理部1100と、WAN側のTCP処理部1000の管理するN個の送信バッファ511およびN個の受信バッファ501と、LAN側のTCP処理部1100の管理するN個の送信バッファ510およびN個の受信バッファ500と、送受信バッファ間でデータの乗せ換えを行うプロキシ900と、N個のエントリを備えた状態テーブル(状態記憶領域)700と、外部の端末240との間で、状態テーブル700の内容などの情報をやり取りするためのインターフェース230とを備える。なお、上述のN個は、それぞれ異なる数でもよい。例えば、送信バッファ、受信バッファは、端末間のパケットをコネクション毎に蓄積する。
TCP処理部1000、1100、プロキシ900については、後に詳述しここでは概略を述べる。
LAN側のTCP処理部1100は、送信履歴更新部1105と、パケット再送部1104と、受信履歴更新部1106と、振分部1108と、集約部1113とを備える。受信履歴更新部1106は、受信したパケットデータを、LAN側受信バッファ500に蓄積する。更に、受信履歴更新部1106は、蓄積したデータに応じて、状態テーブル700のバッファ管理ポインタ(709~711)の情報を更新する。更に、受信履歴更新部1106は、受信したデータの位置を記載したACKパケットを集約部1113経由で返信する。パケット再送部1104は、受信したACKパケットのACK番号に応じて、パケットを再送すると共に、状態テーブル700のバッファ管理ポインタ(715~717)の情報を更新する。送信履歴更新部1105は、LAN側送信バッファ510から読み出した送信データをパケットにして送信すると共に、読み出したデータに応じて、状態テーブル700のバッファ管理ポインタ(715~717)の情報を更新する。
WAN側のTCP処理部1000は、送信帯域制御部1015と、送信履歴更新部1005と、パケット再送部1004と、受信履歴更新部1006と、振分部1016と、集約部1012とを備える。受信履歴更新部1006は、受信したパケットデータを、WAN側受信バッファ501に蓄積する。更に、受信履歴更新部1006は、蓄積したデータに応じて、状態テーブル700のバッファ管理ポインタ(722~724)の情報を更新する。更に、受信履歴更新部1006は、受信したデータの位置を記載したACKパケットを集約部1012経由で返信する。パケット再送部1004は、受信したACKパケットのACK番号に応じて、パケットを再送すると共に、状態テーブル700のバッファ管理ポインタ(728~730)の情報を更新する。送信帯域制御部1015は、送信帯域と再送帯域とACK受信数の情報を状態テーブル700に蓄積する。送信履歴更新部1005は、WAN側送信バッファ511から読み出した送信データをパケットにして送信すると共に、読み出した送信データサイズに応じて、状態テーブル700のバッファ管理ポインタ(728~730)の情報を更新する。
プロキシ900は、データ読出し部(901、906)と、データ加工部(902、905)と、データ書込部(903、904)を備える。データ読出部(901、906)は、受信バッファ(500、501)から読み出したデータサイズに応じて、状態テーブル700のバッファ管理ポインタ(709~711、722~724)の情報を更新する。データ書込部(903、904)は、送信バッファ(510、511)に書き込んだデータサイズに応じて、状態テーブル700のバッファ管理ポインタ(715~717、728~730)の情報を更新する。
WAN側のTCP処理部1000は、送信帯域制御部1015と、送信履歴更新部1005と、パケット再送部1004と、受信履歴更新部1006と、振分部1016と、集約部1012とを備える。受信履歴更新部1006は、受信したパケットデータを、WAN側受信バッファ501に蓄積する。更に、受信履歴更新部1006は、蓄積したデータに応じて、状態テーブル700のバッファ管理ポインタ(722~724)の情報を更新する。更に、受信履歴更新部1006は、受信したデータの位置を記載したACKパケットを集約部1012経由で返信する。パケット再送部1004は、受信したACKパケットのACK番号に応じて、パケットを再送すると共に、状態テーブル700のバッファ管理ポインタ(728~730)の情報を更新する。送信帯域制御部1015は、送信帯域と再送帯域とACK受信数の情報を状態テーブル700に蓄積する。送信履歴更新部1005は、WAN側送信バッファ511から読み出した送信データをパケットにして送信すると共に、読み出した送信データサイズに応じて、状態テーブル700のバッファ管理ポインタ(728~730)の情報を更新する。
プロキシ900は、データ読出し部(901、906)と、データ加工部(902、905)と、データ書込部(903、904)を備える。データ読出部(901、906)は、受信バッファ(500、501)から読み出したデータサイズに応じて、状態テーブル700のバッファ管理ポインタ(709~711、722~724)の情報を更新する。データ書込部(903、904)は、送信バッファ(510、511)に書き込んだデータサイズに応じて、状態テーブル700のバッファ管理ポインタ(715~717、728~730)の情報を更新する。
図5には、送受信バッファ管理用のポインタの説明図を表す。本図では、データを左から右に書き込んでいき、左から右に読み出していくものとする。
受信バッファ500,501は、受信したデータの先頭を示すポインタright_recv(711,724)と、整列済みデータと未整列データの境界を示すポインタleft_recv(710,723)と、プロキシ900がすでに読出し済のデータとまだ読出していないデータの境界を示すleft_rbuf(709,722)と、を管理する。
受信したデータの先頭を示すポインタright_recv(711,724)は、ロスの発生が無く、前から順番にデータを受信すると、受信したデータサイズ分増えて、右へ移動する。受信できずに歯抜けになっているデータ箇所(ロスセグメント)が存在する状態で、再送パケットを受信して、ロスセグメントが消滅すると、整列済みデータと未整列データの境界を示すポインタleft_recv(710,723)は、最も小さなロスセグメントの左端まで移動する。プロキシ900は、読出済データと未読出データの境界を示すleft_rbuf(709,722)から右へ向かって順番にデータを読み出し、読み出したデータサイズ分、left_rbuf(709,722)を右へ移動させる。読み出せるデータサイズの最大値は、left_recv(710,723)とleft_rbuf(709,722)の差である。
送信バッファ510,511は、プロキシ900が書込済みで送信可能な状態となっているデータの先頭を表すポインタright_sbuf(717,730)と、すでに送信済みのデータの先頭を示すポインタright_send(716,729)と、受信側から確認応答を受信済みのデータの先頭を示すポインタleft_send(715,728)と、を管理する。
プロキシ900が書込済みで送信可能な状態となっているデータの先頭を表すポインタright_sbuf(717,730)は、プロキシ900がデータを書き込む毎に、書き込んだデータサイズ分増加し、右へ移動する。送信済みデータの先頭を示すポインタright_send(716,729)を始点として右に向かって新たなデータが送信され、right_send(716,729)は、送信されたデータサイズ分増加し、右へ移動する。受信側から、left_send(715,728)よりも大きな受信シーケンス番号を持つ確認応答パケットを受信すると、left_send(715,728)は、確認応答パケットに記載された受信シーケンス番号へと増加し、右へ移動する。
受信バッファ500,501は、受信したデータの先頭を示すポインタright_recv(711,724)と、整列済みデータと未整列データの境界を示すポインタleft_recv(710,723)と、プロキシ900がすでに読出し済のデータとまだ読出していないデータの境界を示すleft_rbuf(709,722)と、を管理する。
受信したデータの先頭を示すポインタright_recv(711,724)は、ロスの発生が無く、前から順番にデータを受信すると、受信したデータサイズ分増えて、右へ移動する。受信できずに歯抜けになっているデータ箇所(ロスセグメント)が存在する状態で、再送パケットを受信して、ロスセグメントが消滅すると、整列済みデータと未整列データの境界を示すポインタleft_recv(710,723)は、最も小さなロスセグメントの左端まで移動する。プロキシ900は、読出済データと未読出データの境界を示すleft_rbuf(709,722)から右へ向かって順番にデータを読み出し、読み出したデータサイズ分、left_rbuf(709,722)を右へ移動させる。読み出せるデータサイズの最大値は、left_recv(710,723)とleft_rbuf(709,722)の差である。
送信バッファ510,511は、プロキシ900が書込済みで送信可能な状態となっているデータの先頭を表すポインタright_sbuf(717,730)と、すでに送信済みのデータの先頭を示すポインタright_send(716,729)と、受信側から確認応答を受信済みのデータの先頭を示すポインタleft_send(715,728)と、を管理する。
プロキシ900が書込済みで送信可能な状態となっているデータの先頭を表すポインタright_sbuf(717,730)は、プロキシ900がデータを書き込む毎に、書き込んだデータサイズ分増加し、右へ移動する。送信済みデータの先頭を示すポインタright_send(716,729)を始点として右に向かって新たなデータが送信され、right_send(716,729)は、送信されたデータサイズ分増加し、右へ移動する。受信側から、left_send(715,728)よりも大きな受信シーケンス番号を持つ確認応答パケットを受信すると、left_send(715,728)は、確認応答パケットに記載された受信シーケンス番号へと増加し、右へ移動する。
図6には、装置が送受信するパケットのフォーマット図を表す。パケットは、MACヘッダ600、IPヘッダ610、TCPヘッダ620、TCPオプションヘッダ630、ペイロード650を含む。MACヘッダ600は、宛先MACアドレスを表すDMAC601と、送信元MACアドレスを表すSMAC602と、MACフレームタイプを表すType603を含む。IPヘッダ610は、MACヘッダを除くパケット長を表すIP length611と、プロトコル番号を表すprotocol612と、送信元IPアドレスを表すSIP613と、宛先IPアドレスを現すDIP614とを含む。TCPヘッダ620は、送信元ポート番号を表すsrc.port621と、宛先ポート番号を表すdst.port622と、送信シーケンス番号を表すSEQ623と、受信シーケンス番号を表すACK624と、TCPフラグ番号を表すflag625と、TCPのヘッダ長を表すtcp hlen626とを含む。TCPオプションヘッダ630は、オプション種別を表すoption kind631と、オプション長を表すoption length632と、どこからどこまで部分的に受信できたかデータ箇所の位置を送信端末に通知するために用いられるleft_edge_1~4(633、635、637、639)、right_edge_1~4(634、636、638、640)を含む。left_edge_1~4(633、635、637、639)、right_edge_1~4(634、636、638、640)は、部分的に受信できなかったデータ箇所の位置を通知するために用いられるケースもある。更に、TCPオプションヘッダ630は、TCP通信を開始するときに、装置間の情報交換などに使用するケースもある。
例えば、MSS(Maximum Segment Size:最大セグメントサイズ)オプションは、TCP通信を開始するときに、自装置の受信可能なMSSのサイズを対向装置に通知するために用いられる。SACK(Selective Acknowledgments)オプションは、TCP通信を開始するときに、自装置がSACKオプションに対応可能であることを対向装置に通知するために用いられるだけでなく、通信中に廃棄が検出されたときに部分的に受信出来た箇所を対向装置に通知するためにも用いられる。タイムスタンプオプションは、通信中の自装置の受信時刻を対向装置に通知するために用いられる。このように、TCPオプションは、通信開始時および通信中に、自装置の対応可能な機能や情報を対向装置に伝えるために用いられる。
例えば、MSS(Maximum Segment Size:最大セグメントサイズ)オプションは、TCP通信を開始するときに、自装置の受信可能なMSSのサイズを対向装置に通知するために用いられる。SACK(Selective Acknowledgments)オプションは、TCP通信を開始するときに、自装置がSACKオプションに対応可能であることを対向装置に通知するために用いられるだけでなく、通信中に廃棄が検出されたときに部分的に受信出来た箇所を対向装置に通知するためにも用いられる。タイムスタンプオプションは、通信中の自装置の受信時刻を対向装置に通知するために用いられる。このように、TCPオプションは、通信開始時および通信中に、自装置の対応可能な機能や情報を対向装置に伝えるために用いられる。
図7には、状態テーブル700のフォーマット図を示す。
装置200の状態テーブル700は、例えばTCPコネクション毎の状態を記録するためのn個のエントリ701と、通信が確立しているコネクション数を表すconnect_num765と、実際にデータを送信中のコネクション数を表すactive_snd_num766と、装置全体の上限帯域を定めたmax_speed767と、各コネクションの通信量の重み総和を表すweight_sum768と、を有する。TCPの3-Way-Handshakeの終了した通信を、通信が確立しているコネクションであるとみなす。更に、LAN側の受信バッファとWAN側の送信バッファにデータが一定量蓄積されていたり、直近の送信帯域が一定値以上のコネクションを、実際にデータを送信中であるコネクションと見なす。各コネクションの通信量の重みの計算方法は、後述する。なお、上限帯域は、対向拠点(対向装置)毎に定めてもよく、max_speed1~n(767-1~n)として複数の対向拠点1~n毎に異なる値を有しても良い。図18に、対向装置毎に上限帯域max_speed1~n(767-1~n)を有する状態テーブル700-2の例を示す。この場合、図16、17に示す計算には、該当するコネクションに対応する対向装置の上限帯域max_speed767が用いられる。
装置200の状態テーブル700は、例えばTCPコネクション毎の状態を記録するためのn個のエントリ701と、通信が確立しているコネクション数を表すconnect_num765と、実際にデータを送信中のコネクション数を表すactive_snd_num766と、装置全体の上限帯域を定めたmax_speed767と、各コネクションの通信量の重み総和を表すweight_sum768と、を有する。TCPの3-Way-Handshakeの終了した通信を、通信が確立しているコネクションであるとみなす。更に、LAN側の受信バッファとWAN側の送信バッファにデータが一定量蓄積されていたり、直近の送信帯域が一定値以上のコネクションを、実際にデータを送信中であるコネクションと見なす。各コネクションの通信量の重みの計算方法は、後述する。なお、上限帯域は、対向拠点(対向装置)毎に定めてもよく、max_speed1~n(767-1~n)として複数の対向拠点1~n毎に異なる値を有しても良い。図18に、対向装置毎に上限帯域max_speed1~n(767-1~n)を有する状態テーブル700-2の例を示す。この場合、図16、17に示す計算には、該当するコネクションに対応する対向装置の上限帯域max_speed767が用いられる。
各エントリ701は、例えば、エントリが使用中であるか否かを記載するVLD702と、LANまたはWAN側のコネクションが確立中であるか否かを記載するconnect_state703と、LAN側の端末のIPアドレスを表すLIP704と、WAN側の端末のIPアドレスを表すWIP705と、LAN側の端末のTCPポート番号を表すLport706と、WAN側の端末のTCPポート番号を表すWport707と、LAN側のTCP通信の状態を表すlan_state708と、LAN側の受信バッファ管理用のポインタを表すlan_left_rbuf709、lan_left_recv710、lan_right_recv711と、LAN側のウィンドウスケールオプションの値を表すlan_ws712と、LAN側の平均RTTを表すlan_rtt713と、LAN側の受信バッファから読み出され加工中のデータサイズを表すlan_wan714と、LAN側の送信バッファ管理用のポインタを表すlan_left_send715、lan_right_send716、lan_right_sbuf717と、LAN側の輻輳ウィンドウサイズを表すLcwnd718と、LAN側の受信ウィンドウサイズを表すLrwnd719と、LAN側の最大セグメントサイズ(MSS)のサイズを表すLmss720と、WAN側のTCP通信の状態を表すwan_state721と、WAN側の受信バッファ管理用のポインタを表すwan_left_rbuf722、wan_left_recv723、wan_right_recv724と、WAN側のウィンドウスケールオプションの値を表すwan_ws725と、WAN側の平均/初期RTTを表すwan_rtt726と、WAN側の受信バッファから読み出され加工中のデータサイズを表すwan_lan727と、WAN側の送信バッファ管理用のポインタを表すwan_left_send728、wan_right_send729、wan_right_sbuf730と、WAN側の輻輳ウィンドウサイズを表すWcwnd731と、WAN側の受信ウィンドウサイズを表すWrwnd732と、WAN側の最大セグメントサイズMSSを表すWmss733と、前回の更新時刻におけるACK受信済み箇所を表すold_wan_left_send734と、パケットを送信する帯域を制御するための制御帯域token738と、前回の更新時刻における制御帯域を表すold_token739と、前々回の更新時刻における制御帯域を表すold_old_token740と、パケットを送信するために確保する最低限の帯域を表すmin_token741と、輻輳が検出されない状態になった直近の制御帯域を表すt_token742と、直近の定期更新時の制御帯域を表すc_token743と、制御帯域を増加させ始めた直近の時刻を表すinc_time744と、現在時刻での送信帯域を表すsnd745と、前回更新時の送信帯域を表すold_snd746と、前々回の更新時刻の送信帯域を表すold_old_snd747と、現在時刻での再送帯域または廃棄帯域を表すrts748と、前回更新時の再送帯域または廃棄帯域を表すold_rts749と、現在時刻での受信帯域を表すrcv750と、前回更新時の受信帯域を表すold_rcv751と、制御帯域を更新した直近の更新時刻を表すrenewed_time752と、現在時刻での再送率または廃棄率を表すloss_ratio753と、前回更新時の再送率または廃棄率を表すold_loss_ratio754と、制御帯域を更新した前々回の更新時刻を表すold_renewed_time755と、現在時刻での送信バイト積算値を表すsnd_byte756と、現在時刻での再送バイト積算値を表すrts_byte757と、現在時刻での受信バイト積算値を表すack_byte758と、廃棄率の変化率と比較することで輻輳を検出するための閾値K759と、輻輳が発生していないときに一定期間の間は線形増加させるための閾値T760と、必要な通信帯域を記載した通信量重みweight764とを有する。
図9は、プロキシ900のブロック図を示す。
プロキシ900は、LAN側の受信バッファrbuf500からデータを読出すデータ読出し部901と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部902と、加工済みデータをWAN側の送信バッファsbuf511へ書き込むデータ書き込み部903と、WAN側の受信バッファrbuf501からデータを読み出すデータ読出し部906と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部905と、加工済みデータをLAN側の送信バッファsbuf510へ書き込むデータ書き込み部904とを有する。データ加工部902とデータ加工部905との間で、データのやり取りをしてもよい。データの加工は上述の例以外でもよい。
データ読出し部901は、lan_left_rbuf709からlan_left_recv710までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。TLS/SSLヘッダに記載された値からは、復号後のチェックサムやヘッダを除いた平文データサイズを推定することができる。SMBヘッダからは、新規コマンドの作成や付加コマンドのプリフェッチ等を行った後のコマンドデータサイズを推定することができる。推定した加工後のデータサイズを、wan_right_sbuf730とwan_left_send728の差、すなわち未送信データとACK確認待ちデータの合計値に加算しても、WAN側の送信バッファサイズwan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部902へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル700のlan_wan714へ記載する。
もう一つのデータ読出し部906は、wan_left_rbuf722からwan_left_recv723までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。推定した加工後のデータサイズを、lan_right_sbuf717とlan_left_send715の差、すなわち未送信データとACK確認待ちデータの合計値に加算しても、LAN側の送信バッファサイズlan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部905へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル700のwan_lan727へ記載する。
プロキシ900は、LAN側の受信バッファrbuf500からデータを読出すデータ読出し部901と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部902と、加工済みデータをWAN側の送信バッファsbuf511へ書き込むデータ書き込み部903と、WAN側の受信バッファrbuf501からデータを読み出すデータ読出し部906と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部905と、加工済みデータをLAN側の送信バッファsbuf510へ書き込むデータ書き込み部904とを有する。データ加工部902とデータ加工部905との間で、データのやり取りをしてもよい。データの加工は上述の例以外でもよい。
データ読出し部901は、lan_left_rbuf709からlan_left_recv710までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。TLS/SSLヘッダに記載された値からは、復号後のチェックサムやヘッダを除いた平文データサイズを推定することができる。SMBヘッダからは、新規コマンドの作成や付加コマンドのプリフェッチ等を行った後のコマンドデータサイズを推定することができる。推定した加工後のデータサイズを、wan_right_sbuf730とwan_left_send728の差、すなわち未送信データとACK確認待ちデータの合計値に加算しても、WAN側の送信バッファサイズwan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部902へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル700のlan_wan714へ記載する。
もう一つのデータ読出し部906は、wan_left_rbuf722からwan_left_recv723までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。推定した加工後のデータサイズを、lan_right_sbuf717とlan_left_send715の差、すなわち未送信データとACK確認待ちデータの合計値に加算しても、LAN側の送信バッファサイズlan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部905へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル700のwan_lan727へ記載する。
図10には、WAN側のTCP処理部1000のブロック図を示す。
TCP通信を実現するTCP処理部1000は、受信処理を行うRX部(受信部)1002と、送信処理を行うTX部(送信部)1001を有する。
RX部1002は、受信パケットを、SYN,FINなどのフラグが付いたTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部1016と、TCP制御パケットに記載されているフラグ番号に基づいて状態テーブル700内のTCP状態(lan_state708、wan_state721)を変更するTCP制御部1007と、受信したデータパケットの送信シーケンス番号SEQ623と受信シーケンス番号ACK624とに基づいて、状態テーブル700内のバッファ管理ポインタを変更してACKパケットを返信する受信履歴更新部1006を有する。
TX部1001は、状態テーブル700内のTCP状態lan_state708、wan_state721を用いてTCP制御パケットを送信するTCP制御部1003と、受信したACKパケットに基づいて状態テーブル700内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1~4(633、635、636、639)、right_edge_1~4(634、636、638、640)を用いて、送信バッファsbuf511からデータを読み出してパケットを再送すると共に、再送ビット長とACK受信数を送信帯域制御部1015に通知するパケット再送部1004と、送信バッファsbuf511から読み出したデータを載せたパケットを送信して、状態テーブル700内のバッファ管理ポインタを変更すると共に、送信ビット長を送信帯域制御部1015に通知する送信履歴更新部1005と、再送パケットとデータパケットを受け取り、バッファ1~n(1009-1~n)に振り分ける振分部1008と、現在時刻を生成して送信帯域制御部1015に通知するタイマ1013と、インターバル時間(予め定めた固定値、または計測した平均RTTなど)を保存して送信帯域制御部1015に通知するインターバル格納部1014と、状態テーブル700を制御して、各TCPコネクションのトークンサイズをトークン更新部1017に通知する送信帯域制御部1015と、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ1012に通知するトークン更新部1017と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ1012およびバッファ1009,1010,1011とを有する。
TCP通信を実現するTCP処理部1000は、受信処理を行うRX部(受信部)1002と、送信処理を行うTX部(送信部)1001を有する。
RX部1002は、受信パケットを、SYN,FINなどのフラグが付いたTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部1016と、TCP制御パケットに記載されているフラグ番号に基づいて状態テーブル700内のTCP状態(lan_state708、wan_state721)を変更するTCP制御部1007と、受信したデータパケットの送信シーケンス番号SEQ623と受信シーケンス番号ACK624とに基づいて、状態テーブル700内のバッファ管理ポインタを変更してACKパケットを返信する受信履歴更新部1006を有する。
TX部1001は、状態テーブル700内のTCP状態lan_state708、wan_state721を用いてTCP制御パケットを送信するTCP制御部1003と、受信したACKパケットに基づいて状態テーブル700内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1~4(633、635、636、639)、right_edge_1~4(634、636、638、640)を用いて、送信バッファsbuf511からデータを読み出してパケットを再送すると共に、再送ビット長とACK受信数を送信帯域制御部1015に通知するパケット再送部1004と、送信バッファsbuf511から読み出したデータを載せたパケットを送信して、状態テーブル700内のバッファ管理ポインタを変更すると共に、送信ビット長を送信帯域制御部1015に通知する送信履歴更新部1005と、再送パケットとデータパケットを受け取り、バッファ1~n(1009-1~n)に振り分ける振分部1008と、現在時刻を生成して送信帯域制御部1015に通知するタイマ1013と、インターバル時間(予め定めた固定値、または計測した平均RTTなど)を保存して送信帯域制御部1015に通知するインターバル格納部1014と、状態テーブル700を制御して、各TCPコネクションのトークンサイズをトークン更新部1017に通知する送信帯域制御部1015と、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ1012に通知するトークン更新部1017と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ1012およびバッファ1009,1010,1011とを有する。
本実施例において、TX部1001の各ブロックのうち、各TCP通信の制御帯域(最大送信帯域)に従いデータを送信するブロック(例えば、トークン更新部1017、マルチプレクサ1012、バッファ1009等)をまとめて送信制御部と称することもある。 図11には、LAN側のTCP処理部1100のブロック図を示す。
TCP通信を実現するTCP処理部1100は、受信処理を行うRX部(受信部)1102と、送信処理を行うTX部(送信部)1101を有する。
受信処理を行うRX部(受信部)1102は、フィルタ202からの受信パケットをTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部1108と、受信したTCP制御パケットに基づいて状態テーブル700内のTCP状態lan_state708、wan_state721を変更するTCP制御部1107と、受信したデータパケットの送信シーケンス番号SEQ623と受信シーケンス番号ACK624とに基づいて、状態テーブル700内のバッファ管理ポインタを変更してACKパケットを返信し、データパケットのデータを受信バッファrbuf500へ蓄積する受信履歴更新部1106と、を有する。
送信処理を行うTX部(送信部)1101は、状態テーブル700内のTCP状態lan_state708、wan_state721を用いて、TCP制御パケットを送信するTCP制御部1103と、受信したACKパケットに基づいて状態テーブル700内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1~4(633、635、636、639)、right_edge_1~4(634、636、638、640)を用いて送信バッファsbuf510からデータを読み出してパケットを再送するパケット再送部1104と、送信バッファsbuf510から読み出したデータを載せたパケットを送信して、状態テーブル700内のバッファ管理ポインタを変更する送信履歴更新部1105と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ1113およびバッファ1109~1112とを有する。
WAN側TCP処理部1000の送信帯域制御部1015は、状態テーブル700内に、制御帯域を更新した直近の更新時刻を表すrenewed_time752と、制御帯域を更新した前々回の更新時刻を表すold_renewed_time755と、を管理している。直近の更新時刻renewed_time752と、タイマ1013の現在時刻との差が、インターバル格納部1014のインターバル時間よりも大きくなると、直近の更新時刻renewed_time752にインターバル時間を加算して新たな直近の更新時刻renewed_time752とする。加算前の直近の更新時刻renewed_time752は、前々回の更新時刻を表すold_renewed_time755となる。すなわち、直近の更新時刻renewed_time752の一つ前に使用していた直近の更新時刻renewed_time752は、前々回の更新時刻を表すold_renewed_time755となる。インターバル時間には、計測した平均RTTや初期RTT(wan_rtt519)を用いることもあれば、固定値を用いることもある。
TCP通信を実現するTCP処理部1100は、受信処理を行うRX部(受信部)1102と、送信処理を行うTX部(送信部)1101を有する。
受信処理を行うRX部(受信部)1102は、フィルタ202からの受信パケットをTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部1108と、受信したTCP制御パケットに基づいて状態テーブル700内のTCP状態lan_state708、wan_state721を変更するTCP制御部1107と、受信したデータパケットの送信シーケンス番号SEQ623と受信シーケンス番号ACK624とに基づいて、状態テーブル700内のバッファ管理ポインタを変更してACKパケットを返信し、データパケットのデータを受信バッファrbuf500へ蓄積する受信履歴更新部1106と、を有する。
送信処理を行うTX部(送信部)1101は、状態テーブル700内のTCP状態lan_state708、wan_state721を用いて、TCP制御パケットを送信するTCP制御部1103と、受信したACKパケットに基づいて状態テーブル700内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1~4(633、635、636、639)、right_edge_1~4(634、636、638、640)を用いて送信バッファsbuf510からデータを読み出してパケットを再送するパケット再送部1104と、送信バッファsbuf510から読み出したデータを載せたパケットを送信して、状態テーブル700内のバッファ管理ポインタを変更する送信履歴更新部1105と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ1113およびバッファ1109~1112とを有する。
WAN側TCP処理部1000の送信帯域制御部1015は、状態テーブル700内に、制御帯域を更新した直近の更新時刻を表すrenewed_time752と、制御帯域を更新した前々回の更新時刻を表すold_renewed_time755と、を管理している。直近の更新時刻renewed_time752と、タイマ1013の現在時刻との差が、インターバル格納部1014のインターバル時間よりも大きくなると、直近の更新時刻renewed_time752にインターバル時間を加算して新たな直近の更新時刻renewed_time752とする。加算前の直近の更新時刻renewed_time752は、前々回の更新時刻を表すold_renewed_time755となる。すなわち、直近の更新時刻renewed_time752の一つ前に使用していた直近の更新時刻renewed_time752は、前々回の更新時刻を表すold_renewed_time755となる。インターバル時間には、計測した平均RTTや初期RTT(wan_rtt519)を用いることもあれば、固定値を用いることもある。
図2を用いて、LAN側からデータ付きパケットを受信した際の、装置200におけるパケットの流れを説明する。
LAN側から到着したデータ付きパケットは、LAN側TCP処理部1100に入り、受信履歴更新部1106に到着する。受信履歴更新部1106は、ACKパケットを集約部1113経由でLAN側に返信し、パケットに記載されたデータをLAN側受信バッファrbuf500へと蓄積する。更に、蓄積データサイズに基づいて状態テーブル700のポインタを更新する。データ読出し部901は、LAN側受信バッファrbuf500に蓄積された整列済みデータを読出し、データ加工部902へ転送する。更に、読み出したデータサイズに基づいて状態テーブル700のポインタを更新する。データ加工部902は、データを加工して、データ書き込み部903へ転送する。更に、加工中のデータサイズに基づいて状態テーブル700の加工中データサイズを更新する。データ書き込み部903は、加工済みデータをWAN側送信バッファsbuf511へと書き込む。更に、書き込んだデータサイズに基づいて状態テーブル700のポインタを更新する。WAN側送信バッファsbuf511に書き込まれたデータは、WAN側TCP処理部1000の送信履歴更新部1005から読み出されて、WAN側へデータ付きパケットとして送信される。
受信履歴更新部1106についてさらに説明すると、LAN側の受信バッファの最大値から、lan_right_recv711とlan_left_rbuf709との差分を引くことで、受信バッファの残存量を計算する。ペイロード650のサイズが、受信バッファの残存量以下のときは、ペイロード650に記載されたデータ全てを受信バッファに格納する。ペイロード650のサイズが、受信バッファの残存量よりも大きい場合は、ペイロード650の先頭から受信バッファの残存量に相当するサイズのデータだけを受信バッファに格納する。格納データサイズが0よりも大きいときは、データ付きパケットのTCPヘッダ620に記載されたSEQ623の値と、格納データサイズに基づいて、受信バッファ管理用ポインタの更新を行う。例えば、パケットヘッダ記載のSEQ623に格納データサイズを加算した値が、lan_right_recv711よりも大きい場合は、lan_right_recv711を、SEQ623に格納データサイズを加算した値に変更する。更に、受信データの最後尾がlan_right_recv711となるように、受信データをLAN側の受信バッファに記載する。その後、受信バッファ管理ポインタの1つlan_left_recv710をTCPヘッダ620のACK624に記載したACKパケットを、LAN側へ返信する。
また、送信履歴更新部1005について更に説明すると、wan_right_send729から右方向に、最大wan_right_sbuf730までのデータを、WAN側送信バッファsbuf511から読み出す。wan_right_send729は、読み出したデータサイズ分、増加して、右に移動する。更に、読み出したデータをペイロード650に記載し、wan_right_send729をSEQ623に記載したTCPヘッダ620を追加したデータ付きパケットを、WAN側へ送信する。
LAN側から到着したデータ付きパケットは、LAN側TCP処理部1100に入り、受信履歴更新部1106に到着する。受信履歴更新部1106は、ACKパケットを集約部1113経由でLAN側に返信し、パケットに記載されたデータをLAN側受信バッファrbuf500へと蓄積する。更に、蓄積データサイズに基づいて状態テーブル700のポインタを更新する。データ読出し部901は、LAN側受信バッファrbuf500に蓄積された整列済みデータを読出し、データ加工部902へ転送する。更に、読み出したデータサイズに基づいて状態テーブル700のポインタを更新する。データ加工部902は、データを加工して、データ書き込み部903へ転送する。更に、加工中のデータサイズに基づいて状態テーブル700の加工中データサイズを更新する。データ書き込み部903は、加工済みデータをWAN側送信バッファsbuf511へと書き込む。更に、書き込んだデータサイズに基づいて状態テーブル700のポインタを更新する。WAN側送信バッファsbuf511に書き込まれたデータは、WAN側TCP処理部1000の送信履歴更新部1005から読み出されて、WAN側へデータ付きパケットとして送信される。
受信履歴更新部1106についてさらに説明すると、LAN側の受信バッファの最大値から、lan_right_recv711とlan_left_rbuf709との差分を引くことで、受信バッファの残存量を計算する。ペイロード650のサイズが、受信バッファの残存量以下のときは、ペイロード650に記載されたデータ全てを受信バッファに格納する。ペイロード650のサイズが、受信バッファの残存量よりも大きい場合は、ペイロード650の先頭から受信バッファの残存量に相当するサイズのデータだけを受信バッファに格納する。格納データサイズが0よりも大きいときは、データ付きパケットのTCPヘッダ620に記載されたSEQ623の値と、格納データサイズに基づいて、受信バッファ管理用ポインタの更新を行う。例えば、パケットヘッダ記載のSEQ623に格納データサイズを加算した値が、lan_right_recv711よりも大きい場合は、lan_right_recv711を、SEQ623に格納データサイズを加算した値に変更する。更に、受信データの最後尾がlan_right_recv711となるように、受信データをLAN側の受信バッファに記載する。その後、受信バッファ管理ポインタの1つlan_left_recv710をTCPヘッダ620のACK624に記載したACKパケットを、LAN側へ返信する。
また、送信履歴更新部1005について更に説明すると、wan_right_send729から右方向に、最大wan_right_sbuf730までのデータを、WAN側送信バッファsbuf511から読み出す。wan_right_send729は、読み出したデータサイズ分、増加して、右に移動する。更に、読み出したデータをペイロード650に記載し、wan_right_send729をSEQ623に記載したTCPヘッダ620を追加したデータ付きパケットを、WAN側へ送信する。
(WAN側に出て行くデータの送信帯域の制御に使用する変数)
送信帯域制御部1015は、状態テーブル700が管理する変数を用いて、各TCP通信のWAN側に出て行くデータの送信帯域を制御する。
送信帯域制御部1015が管理する状態テーブル700の変数を説明する。状態テーブル700は、コネクション毎に、制御帯域を更新した直近の更新時刻を表すrenewed_time752と、制御帯域を更新した前々回の更新時刻を表すold_renewed_time755と、直近の更新時刻renewed_time752から現在時刻までの送信バイト積算値snd_byte756・再送バイト積算値rts_byte757・受信バイト積算値ack_byte758・制御帯域token738・送信帯域snd745・受信帯域rcv750・再送帯域または廃棄帯域rts748・再送率または廃棄率loss_ratio753と、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの制御帯域old_token739・送信帯域old_snd746・受信帯域old_rcv751・再送帯域または廃棄帯域old_rts749・再送率または廃棄率old_loss_ratio754と、前々回の更新時刻old_renewed_time755前の制御帯域old_old_token740・送信帯域old_old_snd747と、直近の更新時刻renewed_time752におけるACK受信済み箇所old_wan_left_send734と、パケットを送信するために確保する最低限の帯域を表すmin_token741と、輻輳が検出されない状態になった直近の制御帯域を表すt_token742と、直近の定期更新時の制御帯域を表すc_token743と、制御帯域を増加させ始めた直近の時刻を表すinc_time744と、を記録する。
直近の更新時刻renewed_time752後の制御帯域token738は、現在時刻における制御帯域を表す(本実施例では、tokenまたはトークンと表す)。直近の更新時刻renewed_time752後の送信帯域は、現在時刻における送信帯域を表し(本実施例では、sndと表す)、直近の更新時刻renewed_time752後の送信ビット積算値を、現在時刻と直近の更新時刻renewed_time752の差分で除算することで求められる。直近の更新時刻renewed_time752後の再送帯域は、現在時刻における再送帯域を表し(本実施例では、rtsと表す)、直近の更新時刻renewed_time752後の再送ビット積算値を、現在時刻と直近の更新時刻renewed_time752の差分で除算することで求められる。直近の更新時刻renewed_time752後の受信帯域は、現在時刻における受信帯域を表し(本実施例では、rcvと表す)、直近の更新時刻renewed_time752以降のACK受信数にWAN側のMSSと8を積算した値を、現在時刻current_timeと直近の更新時刻renewed_time752の差分で除算することで求められる。直近の更新時刻renewed_time752前の制御帯域・送信帯域・受信帯域・再送帯域は、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの制御帯域・送信帯域・受信帯域・再送帯域の平均値を表す(本実施例では、old_token、old_snd、old_rcv、old_rtsと表す)。前々回の更新時刻old_renewed_time755の制御帯域・送信帯域は、前々回の更新時刻old_renewed_time755の直前までの制御帯域・送信帯域を表す(本実施例では、old_old_token、old_old_snd、と表す)。直近の更新時刻renewed_time752前の再送率/廃棄率old_loss_ratioは、old_rts/old_old_snd、または、1-old_rcv/old_old_sndで求められる。また、直近の更新時刻renewed_time752後の現在時刻の再送率/廃棄率loss_ratioは、rts/old_snd、または、1-rcv/old_sndで求められる。インターバル時間として、固定値を用いることもあれば、状態テーブル700記載のwan_rtt726を用いる場合もある。
送信帯域制御部1015は、状態テーブル700が管理する変数を用いて、各TCP通信のWAN側に出て行くデータの送信帯域を制御する。
送信帯域制御部1015が管理する状態テーブル700の変数を説明する。状態テーブル700は、コネクション毎に、制御帯域を更新した直近の更新時刻を表すrenewed_time752と、制御帯域を更新した前々回の更新時刻を表すold_renewed_time755と、直近の更新時刻renewed_time752から現在時刻までの送信バイト積算値snd_byte756・再送バイト積算値rts_byte757・受信バイト積算値ack_byte758・制御帯域token738・送信帯域snd745・受信帯域rcv750・再送帯域または廃棄帯域rts748・再送率または廃棄率loss_ratio753と、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの制御帯域old_token739・送信帯域old_snd746・受信帯域old_rcv751・再送帯域または廃棄帯域old_rts749・再送率または廃棄率old_loss_ratio754と、前々回の更新時刻old_renewed_time755前の制御帯域old_old_token740・送信帯域old_old_snd747と、直近の更新時刻renewed_time752におけるACK受信済み箇所old_wan_left_send734と、パケットを送信するために確保する最低限の帯域を表すmin_token741と、輻輳が検出されない状態になった直近の制御帯域を表すt_token742と、直近の定期更新時の制御帯域を表すc_token743と、制御帯域を増加させ始めた直近の時刻を表すinc_time744と、を記録する。
直近の更新時刻renewed_time752後の制御帯域token738は、現在時刻における制御帯域を表す(本実施例では、tokenまたはトークンと表す)。直近の更新時刻renewed_time752後の送信帯域は、現在時刻における送信帯域を表し(本実施例では、sndと表す)、直近の更新時刻renewed_time752後の送信ビット積算値を、現在時刻と直近の更新時刻renewed_time752の差分で除算することで求められる。直近の更新時刻renewed_time752後の再送帯域は、現在時刻における再送帯域を表し(本実施例では、rtsと表す)、直近の更新時刻renewed_time752後の再送ビット積算値を、現在時刻と直近の更新時刻renewed_time752の差分で除算することで求められる。直近の更新時刻renewed_time752後の受信帯域は、現在時刻における受信帯域を表し(本実施例では、rcvと表す)、直近の更新時刻renewed_time752以降のACK受信数にWAN側のMSSと8を積算した値を、現在時刻current_timeと直近の更新時刻renewed_time752の差分で除算することで求められる。直近の更新時刻renewed_time752前の制御帯域・送信帯域・受信帯域・再送帯域は、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの制御帯域・送信帯域・受信帯域・再送帯域の平均値を表す(本実施例では、old_token、old_snd、old_rcv、old_rtsと表す)。前々回の更新時刻old_renewed_time755の制御帯域・送信帯域は、前々回の更新時刻old_renewed_time755の直前までの制御帯域・送信帯域を表す(本実施例では、old_old_token、old_old_snd、と表す)。直近の更新時刻renewed_time752前の再送率/廃棄率old_loss_ratioは、old_rts/old_old_snd、または、1-old_rcv/old_old_sndで求められる。また、直近の更新時刻renewed_time752後の現在時刻の再送率/廃棄率loss_ratioは、rts/old_snd、または、1-rcv/old_sndで求められる。インターバル時間として、固定値を用いることもあれば、状態テーブル700記載のwan_rtt726を用いる場合もある。
図8には、前々回の更新時刻old_renewed_time755・直近の更新時刻renewed_time752・現在時刻と、その前後の制御帯域token・送信帯域snd・受信帯域rcv・再送帯域rts・再送率/廃棄率loss_ratioの関係を表す。
直近の更新時刻renewed_time752と前々回の更新時刻old_renewed_time755との差は、インターバル時間である。前々回の更新時刻old_renewed_time755前におけるインターバル時間の制御帯域・送信帯域の平均値は、old_old_token、old_old_sndと表す(801)。前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの間の制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、old_token、old_snd、old_rcv、old_rts、old_loss_ratioと表す(802)。直近の更新時刻renewed_time752から現在時刻current_timeまでの制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、token、snd、rcv、rts、loss_ratioと表す(801)。
送信帯域制御部1015は、状態テーブル700に記載された上述の値を用いて、廃棄率/再送率(loss_ratio753とold_loss_ratio754)を計算する。現在時刻current_timeの廃棄率/再送率loss_ratio753は、rts/old_tokenまたはrts/old_sndまたは1-rcv/old_tokenまたは1-rcv/old_sndで計算される。直近の更新時刻の廃棄率/再送率old_loss_ratio754は、old_rts/old_old_tokenまたはold_rts/old_old_sndまたは1-old_rcv/old_old_tokenまたは1-old_rcv/old_old_sndで計算される。更に、廃棄率/再送率の変化(old_loss_ratio754とloss_ratio753の比率)に基づいて、制御帯域(tokenまたはトークン)を決定し、トークン更新部1017へ伝える。更に、状態テーブル700を更新する。制御帯域(tokenまたはトークン)の更新方法の詳細は、図12~図18に後述する。
トークン更新部1017は、送信帯域制御部1015から伝えられた制御帯域(tokenまたはトークン)の値に基づいて、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ1012に通知する。
直近の更新時刻renewed_time752と前々回の更新時刻old_renewed_time755との差は、インターバル時間である。前々回の更新時刻old_renewed_time755前におけるインターバル時間の制御帯域・送信帯域の平均値は、old_old_token、old_old_sndと表す(801)。前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの間の制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、old_token、old_snd、old_rcv、old_rts、old_loss_ratioと表す(802)。直近の更新時刻renewed_time752から現在時刻current_timeまでの制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、token、snd、rcv、rts、loss_ratioと表す(801)。
送信帯域制御部1015は、状態テーブル700に記載された上述の値を用いて、廃棄率/再送率(loss_ratio753とold_loss_ratio754)を計算する。現在時刻current_timeの廃棄率/再送率loss_ratio753は、rts/old_tokenまたはrts/old_sndまたは1-rcv/old_tokenまたは1-rcv/old_sndで計算される。直近の更新時刻の廃棄率/再送率old_loss_ratio754は、old_rts/old_old_tokenまたはold_rts/old_old_sndまたは1-old_rcv/old_old_tokenまたは1-old_rcv/old_old_sndで計算される。更に、廃棄率/再送率の変化(old_loss_ratio754とloss_ratio753の比率)に基づいて、制御帯域(tokenまたはトークン)を決定し、トークン更新部1017へ伝える。更に、状態テーブル700を更新する。制御帯域(tokenまたはトークン)の更新方法の詳細は、図12~図18に後述する。
トークン更新部1017は、送信帯域制御部1015から伝えられた制御帯域(tokenまたはトークン)の値に基づいて、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ1012に通知する。
(制御帯域tokenの更新処理)
図12の説明図と、図13~図18のフローチャートを用いて、送信帯域制御部1015が制御帯域(tokenまたはトークン)を更新する方法の詳細を説明する。
図12には、独自TCPによる通信を行っている装置の送信側の送信帯域1201、廃棄率1202、廃棄率の変化率1203の時間遷移を示したグラフを示す。本実施の形態では、一例として独自TCPによる通信を用いる例を説明するが、以下に説明する例に限らず、TCP通信及びTCP通信をベースに修正した適宜のプロトコルを適用してもよい。
独自TCPによる通信の送信帯域の増減には、大きく3つのフェーズが存在する。フェーズ1は送信帯域を増加させるステップ、フェーズ2は送信帯域を減少させるステップ、フェーズ3は送信帯域を一定にするステップ、となる。
まず、フェーズ1で送信帯域が増加していき(1204)、ある時にボトルネック帯域を超過する(1213)。送信帯域がボトルネック帯域を超過すると、パケット廃棄が発生するが、廃棄箇所が受信側から送信側に通知されるまでにRTT以上かかる(1215)。そのため、送信帯域がボトルネック帯域を超過したことが、廃棄率の増加となって現れるのは、RTT以上後となる(1214)。廃棄率は、直近の再送帯域をRTT前の送信帯域で除算することで求められる。送信帯域がボトルネック帯域よりも小さい間は、他のトラフィックとの競合による確率的な廃棄しかおきないため、廃棄率はほぼ一定となる(1210)。送信帯域がボトルネック帯域を超過してからRTT以上経過すると、確率的な廃棄に加えて、使い過ぎによる廃棄(1211)が加わるようになるため、廃棄率が増加しはじめる(1212)。廃棄率が増加しはじめると、廃棄率の変化率は1から急激に増加し、閾値kを超過する(1209)。
図12の説明図と、図13~図18のフローチャートを用いて、送信帯域制御部1015が制御帯域(tokenまたはトークン)を更新する方法の詳細を説明する。
図12には、独自TCPによる通信を行っている装置の送信側の送信帯域1201、廃棄率1202、廃棄率の変化率1203の時間遷移を示したグラフを示す。本実施の形態では、一例として独自TCPによる通信を用いる例を説明するが、以下に説明する例に限らず、TCP通信及びTCP通信をベースに修正した適宜のプロトコルを適用してもよい。
独自TCPによる通信の送信帯域の増減には、大きく3つのフェーズが存在する。フェーズ1は送信帯域を増加させるステップ、フェーズ2は送信帯域を減少させるステップ、フェーズ3は送信帯域を一定にするステップ、となる。
まず、フェーズ1で送信帯域が増加していき(1204)、ある時にボトルネック帯域を超過する(1213)。送信帯域がボトルネック帯域を超過すると、パケット廃棄が発生するが、廃棄箇所が受信側から送信側に通知されるまでにRTT以上かかる(1215)。そのため、送信帯域がボトルネック帯域を超過したことが、廃棄率の増加となって現れるのは、RTT以上後となる(1214)。廃棄率は、直近の再送帯域をRTT前の送信帯域で除算することで求められる。送信帯域がボトルネック帯域よりも小さい間は、他のトラフィックとの競合による確率的な廃棄しかおきないため、廃棄率はほぼ一定となる(1210)。送信帯域がボトルネック帯域を超過してからRTT以上経過すると、確率的な廃棄に加えて、使い過ぎによる廃棄(1211)が加わるようになるため、廃棄率が増加しはじめる(1212)。廃棄率が増加しはじめると、廃棄率の変化率は1から急激に増加し、閾値kを超過する(1209)。
独自TCPによる通信では、上記のように、廃棄率の変化率が急激に増加し、閾値kを超過したときに、ネットワークに輻輳が発生したと判断する。
ネットワークに輻輳が発生したと判断すると、RTT前の送信帯域から、現在の再送帯域を引いた値を、新たな送信帯域とする(1218)。RTT前の送信帯域を用いて新たな送信帯域を計算する理由は、送信帯域がボトルネック帯域を超過した時間がRTT以上前だからである。廃棄率の増加はしばらく継続するため(1212)、その間は送信帯域が減少し続ける。この送信帯域を減少させるステップがフェーズ2となる(1205)。 送信帯域が減少していきボトルネック帯域よりも小さくなると、廃棄率が減少しはじめる(1219)。廃棄率の変化率が1よりも小さくなり、閾値kを下回ると(1220)、ネットワークに輻輳が発生しなくなったと判断される。
ネットワークに輻輳が発生しなくなったと判断された後も、廃棄パケットの再送処理は継続している。受信確認済みのデータ箇所がRTT前と比較して増加していない場合は、廃棄パケットの再送処理は継続していると判断して、ACK受信数に応じて、送信帯域を一定とする。この送信帯域を一定とするステップがフェーズ3となる(1206)。
受信確認済みのデータ箇所がRTT前と比較して増加している場合は、廃棄パケットの再送処理が一通り完了したと判断して、再び送信帯域を増加させる(フェーズ1)。
最初は、送信帯域をゆっくりと、例えば、線形的に増加させていく(1207)。一定の期間T、輻輳が検出されないと、その後、送信帯域を急激に(例えば、非線形的に)増加させていく(1208)。非線形的に増加させるときは、RTT毎にαE倍するなど、指数的に増加させてもよい(1216)。最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく期間Tは、RTTとトークン(token:制御帯域)によって定めても良いし、これらの積に比例させてもよい(1221)。また、最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく間は、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させてもよいし、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させる場合の比例係数αLを1よりも小さい値にしてもよい(1217)。
ネットワークに輻輳が発生したと判断すると、RTT前の送信帯域から、現在の再送帯域を引いた値を、新たな送信帯域とする(1218)。RTT前の送信帯域を用いて新たな送信帯域を計算する理由は、送信帯域がボトルネック帯域を超過した時間がRTT以上前だからである。廃棄率の増加はしばらく継続するため(1212)、その間は送信帯域が減少し続ける。この送信帯域を減少させるステップがフェーズ2となる(1205)。 送信帯域が減少していきボトルネック帯域よりも小さくなると、廃棄率が減少しはじめる(1219)。廃棄率の変化率が1よりも小さくなり、閾値kを下回ると(1220)、ネットワークに輻輳が発生しなくなったと判断される。
ネットワークに輻輳が発生しなくなったと判断された後も、廃棄パケットの再送処理は継続している。受信確認済みのデータ箇所がRTT前と比較して増加していない場合は、廃棄パケットの再送処理は継続していると判断して、ACK受信数に応じて、送信帯域を一定とする。この送信帯域を一定とするステップがフェーズ3となる(1206)。
受信確認済みのデータ箇所がRTT前と比較して増加している場合は、廃棄パケットの再送処理が一通り完了したと判断して、再び送信帯域を増加させる(フェーズ1)。
最初は、送信帯域をゆっくりと、例えば、線形的に増加させていく(1207)。一定の期間T、輻輳が検出されないと、その後、送信帯域を急激に(例えば、非線形的に)増加させていく(1208)。非線形的に増加させるときは、RTT毎にαE倍するなど、指数的に増加させてもよい(1216)。最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく期間Tは、RTTとトークン(token:制御帯域)によって定めても良いし、これらの積に比例させてもよい(1221)。また、最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく間は、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させてもよいし、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させる場合の比例係数αLを1よりも小さい値にしてもよい(1217)。
上述の送信帯域の制御方法により、ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させ、その後、送信帯域を非線形的に増加させる通信装置が実現される。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出する通信装置と、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、廃棄率または再送率とそれらの変化率を推定する通信装置と、輻輳を検出したときに、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、送信帯域を減少させる通信装置が実現される。
ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、送信帯域を通常のTCP通信よりも緩やかに(例えば線形的に)増加させることで、通常のTCP通信と競合したときでも、通常のTCP通信の帯域を圧迫することを防ぎ、通常のTCP通信が帯域を確保しやすくなる。また、一定時間が経過した後に、急激に(例えば指数的に)送信帯域を増加させることで、通常のTCP通信との競合が無い時に、送信帯域がボトルネック帯域へ到達してトップスピードになる時間を短くすることが出来る。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、他のトラフィックと競合することで確率的に発生する廃棄と、帯域の使い過ぎによる廃棄を区別することができ、確率的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となり、回線帯域を使い切ることが出来るようになる。更に、帯域の使い過ぎによる廃棄だと判定したときに、過去の送信帯域と現在の再送帯域を用いて帯域を減少させることで、輻輳の規模に応じて帯域を減少させることができる。
ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、送信帯域を通常のTCP通信よりも緩やかに(例えば線形的に)増加させることで、通常のTCP通信と競合したときでも、通常のTCP通信の帯域を圧迫することを防ぎ、通常のTCP通信が帯域を確保しやすくなる。また、一定時間が経過した後に、急激に(例えば指数的に)送信帯域を増加させることで、通常のTCP通信との競合が無い時に、送信帯域がボトルネック帯域へ到達してトップスピードになる時間を短くすることが出来る。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、他のトラフィックと競合することで確率的に発生する廃棄と、帯域の使い過ぎによる廃棄を区別することができ、確率的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となり、回線帯域を使い切ることが出来るようになる。更に、帯域の使い過ぎによる廃棄だと判定したときに、過去の送信帯域と現在の再送帯域を用いて帯域を減少させることで、輻輳の規模に応じて帯域を減少させることができる。
図13~図17には、送信帯域制御部1015が制御帯域(tokenまたはトークン)を更新する方法の詳細を説明するためのフローチャートを示す。
図13~図15には、独自TCPにおける帯域制御の詳細を、図16~図17には、独自TCPによる通信が通信量に応じて最大帯域を分割する方法の詳細を示す。
図13には、送信帯域制御部1015が制御帯域(tokenまたはトークン)を更新する際の概念的なフローチャートを表す。独自TCPでは、送信帯域制御部1015が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。図13の各ステップは、送信帯域制御部1015により実行される。
送信帯域制御部1015において、制御帯域の更新処理がスタートすると(ステップ1301)、ACK確認済み箇所が一定期間増加していないかどうかを判定する(ステップ1302)。ACK確認済み箇所が一定期間増加している場合は、再送に失敗していると判定し、ACK受信数に応じて制御帯域を一定にする(ステップ1306)。例えば、制御帯域token738を受信帯域rcv750とする。ACK確認済み箇所が増加している場合は、パケット再送率(=rts/old_tokenまたはrts/old_sndまたは1-rcv/old_tokenまたは1-rcv/old_sndで計算される値)の増加率が、予め定められた閾値を超過したか否かを判定する(ステップ1303)。パケット再送率の増加率が、予め定められた閾値を超過した場合は、現在の再送帯域(rts)と、過去の(基準時刻より前の)制御帯域(old_token739)または過去の(基準時刻より前の)送信帯域(old_snd746)を用いて、制御帯域(token738)を更新する(ステップ1304)。例えば、過去の(直近の更新時刻renewed_time752より前の)制御帯域を、現在の再送帯域に応じた量減らし、現在時刻の制御帯域とする。一方、ステップ1303において、パケット再送率の増加率が、予め定められた閾値を超過しなかった場合は、制御帯域を増加させる(ステップ1305)。ステップ1304やステップ1305やステップ1306のあとに、各コネクションの最小帯域(min_token741)に基づき、制御帯域(token738)を更新する(ステップ1307)。更に、各コネクションの重みweight764に基づいて、制御帯域tokenを更新する(ステップ1308)。各コネクションの重みweight764の計算方法は後述する。制御帯域(token738)を変更することで、トークンバケツに蓄積されるトークンの量が変わり、それによりパケットの送信レートを変更することが可能となる。
廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、他のトラフィックと競合することで確率的に発生する廃棄と、帯域の使い過ぎによる廃棄を区別することができ、確率的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となり、回線帯域を使い切ることが出来るようになる。更に、帯域の使い過ぎによる廃棄だと判定したときに、過去の送信帯域と現在の再送帯域を用いて帯域を減少させることで、輻輳の規模に応じて帯域を減少させることができる。
図13~図15には、独自TCPにおける帯域制御の詳細を、図16~図17には、独自TCPによる通信が通信量に応じて最大帯域を分割する方法の詳細を示す。
図13には、送信帯域制御部1015が制御帯域(tokenまたはトークン)を更新する際の概念的なフローチャートを表す。独自TCPでは、送信帯域制御部1015が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。図13の各ステップは、送信帯域制御部1015により実行される。
送信帯域制御部1015において、制御帯域の更新処理がスタートすると(ステップ1301)、ACK確認済み箇所が一定期間増加していないかどうかを判定する(ステップ1302)。ACK確認済み箇所が一定期間増加している場合は、再送に失敗していると判定し、ACK受信数に応じて制御帯域を一定にする(ステップ1306)。例えば、制御帯域token738を受信帯域rcv750とする。ACK確認済み箇所が増加している場合は、パケット再送率(=rts/old_tokenまたはrts/old_sndまたは1-rcv/old_tokenまたは1-rcv/old_sndで計算される値)の増加率が、予め定められた閾値を超過したか否かを判定する(ステップ1303)。パケット再送率の増加率が、予め定められた閾値を超過した場合は、現在の再送帯域(rts)と、過去の(基準時刻より前の)制御帯域(old_token739)または過去の(基準時刻より前の)送信帯域(old_snd746)を用いて、制御帯域(token738)を更新する(ステップ1304)。例えば、過去の(直近の更新時刻renewed_time752より前の)制御帯域を、現在の再送帯域に応じた量減らし、現在時刻の制御帯域とする。一方、ステップ1303において、パケット再送率の増加率が、予め定められた閾値を超過しなかった場合は、制御帯域を増加させる(ステップ1305)。ステップ1304やステップ1305やステップ1306のあとに、各コネクションの最小帯域(min_token741)に基づき、制御帯域(token738)を更新する(ステップ1307)。更に、各コネクションの重みweight764に基づいて、制御帯域tokenを更新する(ステップ1308)。各コネクションの重みweight764の計算方法は後述する。制御帯域(token738)を変更することで、トークンバケツに蓄積されるトークンの量が変わり、それによりパケットの送信レートを変更することが可能となる。
廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、他のトラフィックと競合することで確率的に発生する廃棄と、帯域の使い過ぎによる廃棄を区別することができ、確率的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となり、回線帯域を使い切ることが出来るようになる。更に、帯域の使い過ぎによる廃棄だと判定したときに、過去の送信帯域と現在の再送帯域を用いて帯域を減少させることで、輻輳の規模に応じて帯域を減少させることができる。
図14には、送信帯域制御部1015が制御帯域(token738またはトークン)を増加させる際のステップ1305の詳細なフローチャートを示す。
現在時刻current_timeと制御帯域を増加させ始めた直近の時刻を表すinc_time744の差が、閾値T760未満か否かを判定する(ステップ1401)。閾値T760未満の場合は、制御帯域token738をゆっくりと増加させる(ステップ1403)。例えば、係数αLとして、token=token+αL×MSS×8/RTTのように線形増加させる。閾値T760以上のときは、制御帯域tokenを急激に増加させる(ステップ1402)。例えば、係数αEとして、token=αE×tokenのように指数増加させる。
図15には、送信帯域制御部1015が制御帯域(token738またはトークン)を更新する際の詳細なフローチャートを表す。図15は、その一部が図13の処理に相当する。
各ステップは、送信帯域制御部1015により実行される。独自TCPでは、送信帯域制御部1015が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。
制御帯域(token)の更新処理がスタートすると(ステップ1501)、送信帯域制御部1015が、タイマ1013の出力する現在時刻current_timeと、状態テーブル700記載の直近の更新時刻renewed_time752との差が、インターバル格納部1014の出力するインターバル時間以上であるか否かを判定する(ステップ1502)。インターバル時間として、計測したRTTの平均値や初期値等を記録した状態テーブル700のwan_rtt726等を使用してもよい。ステップ1502において真と判断された場合は、直近の更新時刻renewed_time752後の現在の制御帯域tokenの値をtmpに退避させておく(ステップ1503)。更に、ACK確認済み箇所が一定期間で増加したかどうかを判定する。具体的には、ACK確認済み箇所wan_left_sendが、直近の更新時刻renewed_time752におけるACK確認済み箇所old_wan_left_send734よりも大きいか否かを判定する(ステップ1504)。増加している場合は、パケット再送率の増加率が閾値を超過したかどうかを判定する。具体的には、状態テーブル700に記憶された直近の更新時刻renewed_time752から現在時刻current_timeまでの再送帯域または廃棄帯域rts748を、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの送信帯域old_snd746または制御帯域old_token739で割ることで求められる現在時刻curent_timeにおける廃棄率loss_ratio753が、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの再送帯域または廃棄帯域old_rts749を、前々回の更新時刻old_renewed_time755以前の送信帯域old_old_snd747または制御帯域old_old_token740で割ることで求められる直近の更新時刻renewed_time752における旧再送率old_loss_ratio754のK倍(K:予め定められた1以上の係数)よりも大きいか否かを判定する(ステップ1505)。パケット再送率の増加率が閾値を超過した場合は、ネットワークに輻輳が発生したと判断して、制御帯域token738を減少させる(ステップ1506)。図12を用いて説明したフェーズ2に相当する。具体的には、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの制御帯域old_token739から、直近の更新時刻renewed_time752から現在時刻までの再送帯域rts748を減算した値を、新たな制御帯域token738とする。更に、輻輳が検出されない状態になった直近の制御帯域を表すt_token742を新たな制御帯域token738で上書きし、制御帯域を増加させ始めた直近の時刻を表すinc_time744を現在時刻current_timeで上書きする。
現在時刻current_timeと制御帯域を増加させ始めた直近の時刻を表すinc_time744の差が、閾値T760未満か否かを判定する(ステップ1401)。閾値T760未満の場合は、制御帯域token738をゆっくりと増加させる(ステップ1403)。例えば、係数αLとして、token=token+αL×MSS×8/RTTのように線形増加させる。閾値T760以上のときは、制御帯域tokenを急激に増加させる(ステップ1402)。例えば、係数αEとして、token=αE×tokenのように指数増加させる。
図15には、送信帯域制御部1015が制御帯域(token738またはトークン)を更新する際の詳細なフローチャートを表す。図15は、その一部が図13の処理に相当する。
各ステップは、送信帯域制御部1015により実行される。独自TCPでは、送信帯域制御部1015が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。
制御帯域(token)の更新処理がスタートすると(ステップ1501)、送信帯域制御部1015が、タイマ1013の出力する現在時刻current_timeと、状態テーブル700記載の直近の更新時刻renewed_time752との差が、インターバル格納部1014の出力するインターバル時間以上であるか否かを判定する(ステップ1502)。インターバル時間として、計測したRTTの平均値や初期値等を記録した状態テーブル700のwan_rtt726等を使用してもよい。ステップ1502において真と判断された場合は、直近の更新時刻renewed_time752後の現在の制御帯域tokenの値をtmpに退避させておく(ステップ1503)。更に、ACK確認済み箇所が一定期間で増加したかどうかを判定する。具体的には、ACK確認済み箇所wan_left_sendが、直近の更新時刻renewed_time752におけるACK確認済み箇所old_wan_left_send734よりも大きいか否かを判定する(ステップ1504)。増加している場合は、パケット再送率の増加率が閾値を超過したかどうかを判定する。具体的には、状態テーブル700に記憶された直近の更新時刻renewed_time752から現在時刻current_timeまでの再送帯域または廃棄帯域rts748を、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの送信帯域old_snd746または制御帯域old_token739で割ることで求められる現在時刻curent_timeにおける廃棄率loss_ratio753が、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの再送帯域または廃棄帯域old_rts749を、前々回の更新時刻old_renewed_time755以前の送信帯域old_old_snd747または制御帯域old_old_token740で割ることで求められる直近の更新時刻renewed_time752における旧再送率old_loss_ratio754のK倍(K:予め定められた1以上の係数)よりも大きいか否かを判定する(ステップ1505)。パケット再送率の増加率が閾値を超過した場合は、ネットワークに輻輳が発生したと判断して、制御帯域token738を減少させる(ステップ1506)。図12を用いて説明したフェーズ2に相当する。具体的には、前々回の更新時刻old_renewed_time755から直近の更新時刻renewed_time752までの制御帯域old_token739から、直近の更新時刻renewed_time752から現在時刻までの再送帯域rts748を減算した値を、新たな制御帯域token738とする。更に、輻輳が検出されない状態になった直近の制御帯域を表すt_token742を新たな制御帯域token738で上書きし、制御帯域を増加させ始めた直近の時刻を表すinc_time744を現在時刻current_timeで上書きする。
ステップ1505にて、パケット再送率の増加率が閾値を超過しなかった場合は、ネットワークに輻輳が発生していないと判断して、制御帯域token738を増加させる(ステップ1507)。図12を用いて説明したフェーズ1に相当する。具体的には、係数αLとして、token=token+αL×MSS×8/RTTのように線形増加させたり、係数αEとして、token=αE×tokenのように指数増加させたりする。ステップ1504において、ACK確認済み箇所が一定期間で増加しなかった場合は、パケットの再送が継続中であると判断して、ACK受信数に応じて制御帯域token738を一定に保つ(ステップ1508)。図12を用いて説明したフェーズ3に相当する。具体的には、制御帯域token738を、直近の更新時刻renewed_time752から現在時刻current_timeまでの受信帯域rcv750とする。更に、輻輳が検出されない状態になった直近の制御帯域を表すt_token742を新たな制御帯域token738で上書きし、制御帯域を増加させ始めた直近の時刻を表すinc_time744を現在時刻current_timeで上書きする。
ステップ1506~1508の処理が終了すると、状態テーブル700の管理する値を更新する。例えば、前々回の更新時刻old_renewed_time755における送信帯域old_old_snd747=前回の更新時刻renewed_time752における送信帯域old_snd746、前回の更新時刻renewed_time752における送信帯域old_snd746=現在時刻current_timeにおける送信帯域snd745、前回の更新時刻renewed_time752における再送帯域old_rts749=現在時刻current_timeにおける再送帯域rts748、前々回の更新時刻old_renewed_time755=前回更新時刻renewed_time752、前回更新時刻renewed_time752=前回更新時刻renewed_time752+インターバルinterval、送信バイト積算値snd_byte756=0、再送バイト積算値rts_byte757=0、受信バイト積算値ack_byte758=0、前々回の更新時刻old_renewed_time755における制御帯域old_old_token740=前回更新時刻renewed_time752における制御帯域old_token739、前回更新時刻renewed_time752における制御帯域old_token739=tmp、前回の更新時の制御帯域c_token743=新たな制御帯域token748、などと更新し、状態テーブル700に記録する(ステップ1509)。その後、ステップ1512に移る。
ステップ1506~1508の処理が終了すると、状態テーブル700の管理する値を更新する。例えば、前々回の更新時刻old_renewed_time755における送信帯域old_old_snd747=前回の更新時刻renewed_time752における送信帯域old_snd746、前回の更新時刻renewed_time752における送信帯域old_snd746=現在時刻current_timeにおける送信帯域snd745、前回の更新時刻renewed_time752における再送帯域old_rts749=現在時刻current_timeにおける再送帯域rts748、前々回の更新時刻old_renewed_time755=前回更新時刻renewed_time752、前回更新時刻renewed_time752=前回更新時刻renewed_time752+インターバルinterval、送信バイト積算値snd_byte756=0、再送バイト積算値rts_byte757=0、受信バイト積算値ack_byte758=0、前々回の更新時刻old_renewed_time755における制御帯域old_old_token740=前回更新時刻renewed_time752における制御帯域old_token739、前回更新時刻renewed_time752における制御帯域old_token739=tmp、前回の更新時の制御帯域c_token743=新たな制御帯域token748、などと更新し、状態テーブル700に記録する(ステップ1509)。その後、ステップ1512に移る。
一方、ステップ1502で、偽と判定された場合は、ACK確認済データ末尾を表すポインタwan_left_send728が、前回の更新時刻renewed_time752におけるACK確認済データ末尾を表すポインタold_wan_left_send734よりも増加しており、尚且つ、パケット廃棄率や再送率の変化率(loss_ratio753÷old_loss_ratio754)が、予め定められた閾値K759を超過しているか否かを判定する(ステップ1510)。Kの値は、固定としてもよいし、tokenの値に応じて変化してもよい。ステップ1510において真と判定した場合は、ネットワークに輻輳が発生していると判断して、ステップ1506と同様に、前回更新時刻renewed_time752における制御帯域old_token739の値よりも小さくなるように、新たな制御帯域token738の値を決定する(ステップ1511)。例えば、再送/廃棄帯域rts748を用いて減少させる。例えば、新たな制御帯域token738=前回更新時刻renewed_time752における制御帯域old_token739-再送帯域または廃棄帯域rts748などとする(ステップ1511)。ステップ1510において偽と判定した場合は、何もしない。これらのステップにより、インターバル時間が経過しなくても、再送率の増加からネットワークの輻輳を即座に検出し、制御帯域を減少させることができる。これらのステップの後、ステップ1512に移る。
ステップ1512では、制御帯域token738が、各TCP通信の最低保証帯域min_token741よりも小さい場合は、制御帯域token738を各TCP通信の最低保証帯域min_token741に変更する(ステップ1512)。すなわち図15のステップ1512で示す2つの式で定まるtokenのうちいずれか小さいほうをとる。なお、ステップ1512におけるtoken738やmin_token741などのデータは、状態テーブル700を参照して読み出すことができる。このステップの後、ステップ1513に移る。
ステップ1513では、制御帯域token738が、各TCP通信の通信量重みweight764により定まる最大帯域max_token770よりも大きい場合は、制御帯域token738を最大帯域max_token770に変更する(ステップ1513)。通信量重みweight764により定まる最大帯域max_token770は、後述するフローチャートで決定する。
ステップ1512では、制御帯域token738が、各TCP通信の最低保証帯域min_token741よりも小さい場合は、制御帯域token738を各TCP通信の最低保証帯域min_token741に変更する(ステップ1512)。すなわち図15のステップ1512で示す2つの式で定まるtokenのうちいずれか小さいほうをとる。なお、ステップ1512におけるtoken738やmin_token741などのデータは、状態テーブル700を参照して読み出すことができる。このステップの後、ステップ1513に移る。
ステップ1513では、制御帯域token738が、各TCP通信の通信量重みweight764により定まる最大帯域max_token770よりも大きい場合は、制御帯域token738を最大帯域max_token770に変更する(ステップ1513)。通信量重みweight764により定まる最大帯域max_token770は、後述するフローチャートで決定する。
図15に記載したフローチャートに基づいて制御帯域token738を変更することで、トークンバケツに蓄積されるトークンの量が変わり、それによりパケットの送信レートを変更することが可能となる。更に、廃棄率または再送率に基づく帯域制御を行うことで、バースト的なトラフィックとの競合により確率的に発生する廃棄の影響を受けずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させることが出来るようになる。これにより、独自TCPは、RTTと廃棄率に依存せずに、回線帯域を使い切ることが出来る。
図16には、送信帯域制御部1015が、各TCP通信の通信量重みweight764を計算するためのフローチャートを示す。本フローチャートは、図15のステップS1513の前の適宜のタイミングで実行される。例えば、インターバル毎に実行されてもよいし、他の適宜のタイミングで実行されてもよい。
通信量重み(weight764)の更新処理がスタートすると(ステップ1600)、送信帯域制御部1015は、LAN側の受信バッファとWAN側の送信バッファに蓄積されたデータのビット量である(wan_right_sbuf730-wan_left_send728+lan_right_recv711-lan_left_rbuf709)×8を、WAN側のRTTであるwan_rtt726で割った値を、weight764に代入する(ステップ1601)。これは、装置200に滞留したデータを1RTTで送り切れる値を必要な帯域と見なす考えに基づいている。次に、送信帯域制御部1015は、装置200の最大帯域であるmax_speed767を、実際にデータを送信中のコネクション数を表すactive_snd_num766で割った値よりも、通信量重みweight764が大きいか否かを判定する(ステップ1602)。なお、LAN側の受信バッファとWAN側の送信バッファに蓄積されたデータのバイト量(wan_right_sbuf730-wan_left_send728+lan_right_recv711-lan_left_rbuf709)が一定値以上のコネクションや、現在時刻current_timeにおける送信帯域snd745が一定値以上のコネクションを、実際にデータを送信中であるコネクションと見なす。ステップ1602において真と判定した場合は、送信帯域制御部1015は、装置の最大帯域max_speed767をデータ送信中のコネクション数active_snd_num766で等分割した値を、通信量重みweight764に代入する(ステップ1603)。
上記のフローチャートを用いて、通信量重みweight764を、公平分配したときの帯域以下に制限することで、通信量の多い通信が帯域を使い過ぎるのを防ぐことが可能となる。
図16には、送信帯域制御部1015が、各TCP通信の通信量重みweight764を計算するためのフローチャートを示す。本フローチャートは、図15のステップS1513の前の適宜のタイミングで実行される。例えば、インターバル毎に実行されてもよいし、他の適宜のタイミングで実行されてもよい。
通信量重み(weight764)の更新処理がスタートすると(ステップ1600)、送信帯域制御部1015は、LAN側の受信バッファとWAN側の送信バッファに蓄積されたデータのビット量である(wan_right_sbuf730-wan_left_send728+lan_right_recv711-lan_left_rbuf709)×8を、WAN側のRTTであるwan_rtt726で割った値を、weight764に代入する(ステップ1601)。これは、装置200に滞留したデータを1RTTで送り切れる値を必要な帯域と見なす考えに基づいている。次に、送信帯域制御部1015は、装置200の最大帯域であるmax_speed767を、実際にデータを送信中のコネクション数を表すactive_snd_num766で割った値よりも、通信量重みweight764が大きいか否かを判定する(ステップ1602)。なお、LAN側の受信バッファとWAN側の送信バッファに蓄積されたデータのバイト量(wan_right_sbuf730-wan_left_send728+lan_right_recv711-lan_left_rbuf709)が一定値以上のコネクションや、現在時刻current_timeにおける送信帯域snd745が一定値以上のコネクションを、実際にデータを送信中であるコネクションと見なす。ステップ1602において真と判定した場合は、送信帯域制御部1015は、装置の最大帯域max_speed767をデータ送信中のコネクション数active_snd_num766で等分割した値を、通信量重みweight764に代入する(ステップ1603)。
上記のフローチャートを用いて、通信量重みweight764を、公平分配したときの帯域以下に制限することで、通信量の多い通信が帯域を使い過ぎるのを防ぐことが可能となる。
図17には、送信帯域制御部1015が、各TCP通信の最大帯域max_token770を、通信量重みweight764を用いて計算するためのフローチャートを示す。
各TCP通信の最大帯域(max_token770)の更新処理がスタートすると(ステップ1700)、装置200の最大帯域max_speed767をデータ送信中のコネクション数active_snd_num766で等分割した値を、通信量重みweight764の総和Σweight(weight_sum768)で割った値に、装置200の最大帯域max_speed767を掛けた値を、各TCP通信の最大帯域max_token770に代入する(ステップ1701)。これは、通信量重みweight764の総和Σweightのうち、通信量重みweight764の取り得る最大値分を、各通信の最大値として割り当てることを意味する。通信量重みweight764の総和Σweightが、装置200の最大帯域max_speed767をデータ送信中のコネクション数active_snd_num766で等分割した値よりも小さい場合(ステップ1702)、通信量の少ない通信ばかりで、装置200の最大帯域max_speed767を使い切れないケースと考えて、各TCP通信の最大帯域max_token770を、装置200の最大帯域max_speed767とする(ステップ1703)。
図4には、図15~図17のフローチャートに従い制御帯域token738を変更することで、通信量の少ない1つの通信と、通信量の多い2つの通信が同時に行われる時に、装置200の最大帯域max_speed767がどのように分割されるかを示す。
通信量の少ない通信401は、通信量の多い2つの通信402、403に帯域を圧迫されずに、必要な帯域を使用できる。一方、通信量の多い2つの通信402、403は、通信量の少ない通信401の余らせた帯域を等分割しつつ使い切ることができる。
なお、装置200は、状態テーブル700内のtoken738やsnd745などの値を用いることで、インターフェース230を経由して、図4に示したような通信毎のスループットの時間推移を、外部の端末240に表示させてもよい。
このように、図15~図17のフローチャートに従い、通信量重みweight764を用いて、各TCP通信の最大帯域max_token770を決定し、制御帯域token738を各TCP通信の最大帯域max_token770以下に制限することで、通信量の少ない通信の帯域を保護しつつ、通信量の多い通信が残された帯域を公平に分割しつつ使い切ることが可能となる。
各TCP通信の最大帯域(max_token770)の更新処理がスタートすると(ステップ1700)、装置200の最大帯域max_speed767をデータ送信中のコネクション数active_snd_num766で等分割した値を、通信量重みweight764の総和Σweight(weight_sum768)で割った値に、装置200の最大帯域max_speed767を掛けた値を、各TCP通信の最大帯域max_token770に代入する(ステップ1701)。これは、通信量重みweight764の総和Σweightのうち、通信量重みweight764の取り得る最大値分を、各通信の最大値として割り当てることを意味する。通信量重みweight764の総和Σweightが、装置200の最大帯域max_speed767をデータ送信中のコネクション数active_snd_num766で等分割した値よりも小さい場合(ステップ1702)、通信量の少ない通信ばかりで、装置200の最大帯域max_speed767を使い切れないケースと考えて、各TCP通信の最大帯域max_token770を、装置200の最大帯域max_speed767とする(ステップ1703)。
図4には、図15~図17のフローチャートに従い制御帯域token738を変更することで、通信量の少ない1つの通信と、通信量の多い2つの通信が同時に行われる時に、装置200の最大帯域max_speed767がどのように分割されるかを示す。
通信量の少ない通信401は、通信量の多い2つの通信402、403に帯域を圧迫されずに、必要な帯域を使用できる。一方、通信量の多い2つの通信402、403は、通信量の少ない通信401の余らせた帯域を等分割しつつ使い切ることができる。
なお、装置200は、状態テーブル700内のtoken738やsnd745などの値を用いることで、インターフェース230を経由して、図4に示したような通信毎のスループットの時間推移を、外部の端末240に表示させてもよい。
このように、図15~図17のフローチャートに従い、通信量重みweight764を用いて、各TCP通信の最大帯域max_token770を決定し、制御帯域token738を各TCP通信の最大帯域max_token770以下に制限することで、通信量の少ない通信の帯域を保護しつつ、通信量の多い通信が残された帯域を公平に分割しつつ使い切ることが可能となる。
なお、上述の例ではRTT(往復遅延時間)を用いて計算したが、これ以外の通信遅延時間を用いてもよい。
ここで、制御帯域の上限を制限することで、図4のように通信量の多い通信が余剰の帯域を使うことができる点について補足して説明する。図12及び図14を参照して述べたフェーズ1では、通信量の少ない通信(コネクション)でも制御帯域(token)が増加していく(図12:1204、1207、1208。図15:1507)。この制御帯域の上限は、図15のステップS1513で制限される。仮に図16及び図17を省略すると、最大帯域をコネクション数で分割したものを上限とし、図3の状態となる場合がある。
本実施の形態では、通信量の多い通信(コネクション)が他にあると、通信量重みweightが大きくなるので、各コネクションの最大制御帯域max_tokenが従来より小さくなる。従って、通信量の少ない通信の制御帯域は、従来よりも上限が制限され、送信帯域が制限される。通信量の多い通信のバッファ蓄積データ量が多いほどmax_tokenは小さくなり、RTTが小さいほどmax_tokenは小さくなる。
よって、通信量の少ない通信の最低帯域はステップ1512で確保されつつも、通信量の多い通信のバッファ蓄積データ量が多いほど、またRTTが小さいほど、通信量の少ない通信の最大制御帯域は制限され、結果として通信量の多い通信が帯域を使うことができる。
ここで、制御帯域の上限を制限することで、図4のように通信量の多い通信が余剰の帯域を使うことができる点について補足して説明する。図12及び図14を参照して述べたフェーズ1では、通信量の少ない通信(コネクション)でも制御帯域(token)が増加していく(図12:1204、1207、1208。図15:1507)。この制御帯域の上限は、図15のステップS1513で制限される。仮に図16及び図17を省略すると、最大帯域をコネクション数で分割したものを上限とし、図3の状態となる場合がある。
本実施の形態では、通信量の多い通信(コネクション)が他にあると、通信量重みweightが大きくなるので、各コネクションの最大制御帯域max_tokenが従来より小さくなる。従って、通信量の少ない通信の制御帯域は、従来よりも上限が制限され、送信帯域が制限される。通信量の多い通信のバッファ蓄積データ量が多いほどmax_tokenは小さくなり、RTTが小さいほどmax_tokenは小さくなる。
よって、通信量の少ない通信の最低帯域はステップ1512で確保されつつも、通信量の多い通信のバッファ蓄積データ量が多いほど、またRTTが小さいほど、通信量の少ない通信の最大制御帯域は制限され、結果として通信量の多い通信が帯域を使うことができる。
(構成例)
通信装置の一形態は、第一の通信装置からネットワークを介して第二の通信装置に送信されるパケットに関する帯域をインターバル毎に管理し、インターバルの送信帯域が一定値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する。
通信装置の他の形態は、第一の通信装置からネットワークを介して第二の通信装置に送信されるパケットをコネクション毎に蓄積するバッファを備え、バッファに蓄積されたパケットのデータサイズが一定値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する。
上述の各通信装置において、前記装置から送信されるパケットの最大帯域を定めて、前記最大帯域を前記コネクションの数で割った値に基づいて各コネクションの上限帯域を制限してもよい。
上述の各通信装置において、対向装置毎に定めた最大帯域を前記コネクションの数で割った値に基づいて各コネクションの上限帯域を制限してもよい。
上述の通信装置において、コネクション毎に往復遅延時間を計測し、各コネクションのバッファ蓄積量を往復遅延時間で割った値に基づいて各コネクションの上限帯域を制限してもよい。
上述の通信装置において、最大帯域をコネクション数で割った値と、各コネクションのバッファ蓄積量を往復遅延時間で割った値の、いずれか大きい値に基づいて各コネクションの上限帯域を制限してもよい。
上述の通信装置において、各コネクション毎に計測した廃棄率とその変化に基づいて、各コネクションの送信帯域を制御してもよい。
上述の通信装置において、各コネクション毎に計測した過去のインターバルの制御帯域と直近のインターバルの再送帯域・廃棄帯域に基づいて各コネクションの送信帯域を制御してもよい。
通信装置の一形態は、第一の通信装置からネットワークを介して第二の通信装置に送信されるパケットに関する帯域をインターバル毎に管理し、インターバルの送信帯域が一定値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する。
通信装置の他の形態は、第一の通信装置からネットワークを介して第二の通信装置に送信されるパケットをコネクション毎に蓄積するバッファを備え、バッファに蓄積されたパケットのデータサイズが一定値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する。
上述の各通信装置において、前記装置から送信されるパケットの最大帯域を定めて、前記最大帯域を前記コネクションの数で割った値に基づいて各コネクションの上限帯域を制限してもよい。
上述の各通信装置において、対向装置毎に定めた最大帯域を前記コネクションの数で割った値に基づいて各コネクションの上限帯域を制限してもよい。
上述の通信装置において、コネクション毎に往復遅延時間を計測し、各コネクションのバッファ蓄積量を往復遅延時間で割った値に基づいて各コネクションの上限帯域を制限してもよい。
上述の通信装置において、最大帯域をコネクション数で割った値と、各コネクションのバッファ蓄積量を往復遅延時間で割った値の、いずれか大きい値に基づいて各コネクションの上限帯域を制限してもよい。
上述の通信装置において、各コネクション毎に計測した廃棄率とその変化に基づいて、各コネクションの送信帯域を制御してもよい。
上述の通信装置において、各コネクション毎に計測した過去のインターバルの制御帯域と直近のインターバルの再送帯域・廃棄帯域に基づいて各コネクションの送信帯域を制御してもよい。
本実施の形態の一態様によると、
LAN側とWAN側の複数のTCP通信を中継する通信装置が、
各TCP通信の送信帯域を制御する帯域制御部と、
各TCP通信のLAN側から受信したデータを蓄積する受信バッファと、
各TCP通信のWAN側へ送信するデータを蓄積する送信バッファと、
各TCP通信の受信確認済みのデータ箇所の履歴を記録する状態テーブルと、
各TCP通信における送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴を記録する帯域テーブルと、
を有し、
帯域制御部が、
状態テーブルに記載の送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴と、状態テーブルに記載の受信確認済みのデータ箇所の履歴と基づいて、TCP通信の輻輳の有無と、受信確認済みのデータ箇所が更新中か否かを判定し、輻輳が検出されず、受信確認済みのデータ箇所が更新中のときは、TCP通信の送信帯域を増加させ、輻輳が検出されたときはTCP通信の送信帯域を減少させ、
送信バッファと受信バッファに蓄積されたデータ量が一定値以上のコネクション数、あるいは、過去の送信帯域が一定値以上のコネクション数と、送信バッファと受信バッファに蓄積されたデータ量を往復遅延時間で割った値と、に基づいて各コネクションの上限帯域を制限する通信装置が提供される。
LAN側とWAN側の複数のTCP通信を中継する通信装置が、
各TCP通信の送信帯域を制御する帯域制御部と、
各TCP通信のLAN側から受信したデータを蓄積する受信バッファと、
各TCP通信のWAN側へ送信するデータを蓄積する送信バッファと、
各TCP通信の受信確認済みのデータ箇所の履歴を記録する状態テーブルと、
各TCP通信における送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴を記録する帯域テーブルと、
を有し、
帯域制御部が、
状態テーブルに記載の送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴と、状態テーブルに記載の受信確認済みのデータ箇所の履歴と基づいて、TCP通信の輻輳の有無と、受信確認済みのデータ箇所が更新中か否かを判定し、輻輳が検出されず、受信確認済みのデータ箇所が更新中のときは、TCP通信の送信帯域を増加させ、輻輳が検出されたときはTCP通信の送信帯域を減少させ、
送信バッファと受信バッファに蓄積されたデータ量が一定値以上のコネクション数、あるいは、過去の送信帯域が一定値以上のコネクション数と、送信バッファと受信バッファに蓄積されたデータ量を往復遅延時間で割った値と、に基づいて各コネクションの上限帯域を制限する通信装置が提供される。
本発明は、例えば端末間の通信を中継する通信装置に利用可能である。
200 通信装置
110、120、130 ネットワーク
111、121、131 端末
191、192、193 回線
1000、1100 処理部
1015 送信帯域制御部
500、501 受信バッファ
510、511 送信バッファ
900 プロキシ
700 状態テーブル
502、503、504 ポインタ
600 ヘッダデータ
701 エントリ
110、120、130 ネットワーク
111、121、131 端末
191、192、193 回線
1000、1100 処理部
1015 送信帯域制御部
500、501 受信バッファ
510、511 送信バッファ
900 プロキシ
700 状態テーブル
502、503、504 ポインタ
600 ヘッダデータ
701 エントリ
Claims (15)
- 第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するバッファと、
設定される各コネクションの制御帯域に応じて、各コネクションの送信帯域を制御する帯域制御部と
を備え、
前記帯域制御部は、各コネクションについて、前記バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、前記制御帯域の上限を制限する通信装置。 - 請求項1の通信装置において、
各コネクションについて、前記バッファに蓄積されたパケットの蓄積量を、通信遅延時間で割った値に基づいて前記制御帯域の上限を制限する通信装置。 - 請求項1の通信装置において、
送信したパケットに対する受信確認を受領済みのデータ箇所を記憶する状態テーブル
をさらに備え、
前記帯域制御部は、
所定のコネクションにおいて輻輳が検出されず、かつ、前記状態テーブルの受信確認済みのデータ箇所が所定時間内に更新されているときは、該コネクションの送信帯域を増加させ、
輻輳が検出されたときは該コネクションの送信帯域を減少させる通信装置。 - 請求項3の通信装置において、
前記帯域制御部が、
予め定められた最大帯域と、前記バッファに蓄積されたデータ量が予め定められた閾値以上のコネクションの数、又は、過去の送信帯域が予め定められた閾値以上のコネクションの数と、前記バッファに蓄積されたパケットの蓄積量を通信遅延時間で割った値と、に基づいて前記制御帯域の上限を制限する通信装置。 - 請求項3の通信装置において、
前記バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、少なくとも通信量が他のコネクションよりも少ないコネクションについて、制御帯域の上限を、予め定められた最大帯域をコネクション数で割った値よりも小さくして送信帯域を制限し、他のコネクションが予め定められた最大帯域をコネクション数で割った値より大きな帯域を利用可能にする通信装置。 - 請求項4の通信装置において、
前記バッファに蓄積されたパケットの蓄積量を通信遅延時間で割った値が、前記最大帯域を前記コネクションの数で割った値より大きい場合、前記最大帯域を前記コネクションの数で割った値に基づいて前記制御帯域の上限を制限する通信装置。 - 請求項1の通信装置において、
前記第一の装置からネットワークを介して前記第二の装置に送信されるパケットに関する過去の送信帯域をインターバル毎に管理し、インターバルの送信帯域が予め定められた閾値以上のコネクションの数と、前記バッファに蓄積されたパケットの蓄積量を通信遅延時間で割った値と、に基づいて各コネクションの制御帯域の上限を制限する通信装置。 - 請求項1の通信装置において、
前記バッファに蓄積されたデータ量が予め定められた閾値以上のコネクションの数と、前記バッファに蓄積されたパケットの蓄積量を通信遅延時間で割った値と、に基づいて各コネクションの制御帯域の上限を制限する通信装置。 - 請求項1の通信装置において、
前記最大帯域が対向装置毎に定められ、該対向装置に対応するコネクションについて、該対向装置に対する最大帯域をコネクションの数で割った値に基づいて、該対向装置に対応する各コネクションの制御帯域の上限を制限する通信装置。 - 請求項1の通信装置において、
前記帯域制御部が、コネクション毎に計測した廃棄率とその変化に基づいて、各コネクションの送信帯域を制御する通信装置。 - 請求項1の通信装置において、
前記帯域制御部が、コネクション毎に計測した過去のインターバルの制御帯域と、直近のインターバルの再送帯域及び廃棄帯域とに基づいて各コネクションの送信帯域を制御する通信装置。 - 第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するステップと、
設定される各コネクションの制御帯域に応じて、各コネクションの送信帯域を制御するステップと
各コネクションについて、前記バッファに蓄積された各コネクションのパケットの蓄積量と、各コネクションの通信遅延時間とに基づいて、前記制御帯域の上限値を求めるステップと
を含む送信帯域制御方法。 - 第一の装置からネットワークを介して第二の装置に送信されるパケットをコネクション毎に蓄積するバッファと、
帯域制御部と
を備え、
前記帯域制御部は、
前記バッファに蓄積されたパケットのデータサイズが予め定められた閾値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する、又は、
前記第一の装置からネットワークを介して前記第二の装置に送信されるパケットに関する送信帯域を所定のインターバル毎に管理し、インターバルの送信帯域が予め定められた閾値以上のコネクションの数に基づいて各コネクションの上限帯域を制限する通信装置。 - 請求項13の通信装置において、
前記通信装置から送信されるパケットの最大帯域が予め定められ、前記最大帯域を前記コネクションの数で割った値に基づいて各コネクションの上限帯域を制限する通信装置。 - 請求項14の通信装置において、
前記通信装置から送信されるパケットの最大帯域が対向装置毎に定められ、コネクションに対応する対向装置との最大帯域を、該対向装置とのコネクションの数で割った値に基づいて各コネクションの上限帯域を制限する通信装置。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2013168106A JP2016201579A (ja) | 2013-08-13 | 2013-08-13 | 通信装置及び送信帯域制御方法 |
JP2013-168106 | 2013-08-13 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015022809A1 true WO2015022809A1 (ja) | 2015-02-19 |
Family
ID=52468199
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2014/065670 WO2015022809A1 (ja) | 2013-08-13 | 2014-06-13 | 通信装置及び送信帯域制御方法 |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP2016201579A (ja) |
WO (1) | WO2015022809A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110273550A (zh) * | 2019-05-22 | 2019-09-24 | 中联重科股份有限公司 | 泵送设备的配对自控方法及控制装置 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7063285B2 (ja) * | 2019-02-07 | 2022-05-09 | 日本電信電話株式会社 | 通信制御装置、および、通信制御方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008053995A (ja) * | 2006-08-24 | 2008-03-06 | Kddi Corp | 通信放送連携システムにおける端末のレート制御方法、端末、システム及びプログラム |
JP2013027010A (ja) * | 2011-07-26 | 2013-02-04 | Hitachi Ltd | 通信装置 |
JP2013027007A (ja) * | 2011-07-26 | 2013-02-04 | Hitachi Ltd | 通信装置 |
-
2013
- 2013-08-13 JP JP2013168106A patent/JP2016201579A/ja active Pending
-
2014
- 2014-06-13 WO PCT/JP2014/065670 patent/WO2015022809A1/ja active Application Filing
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008053995A (ja) * | 2006-08-24 | 2008-03-06 | Kddi Corp | 通信放送連携システムにおける端末のレート制御方法、端末、システム及びプログラム |
JP2013027010A (ja) * | 2011-07-26 | 2013-02-04 | Hitachi Ltd | 通信装置 |
JP2013027007A (ja) * | 2011-07-26 | 2013-02-04 | Hitachi Ltd | 通信装置 |
Non-Patent Citations (1)
Title |
---|
TAKEKI YAZAKI ET AL.: "Network Acceleration Technology for Cloud Computing", HITACHI HYORON, vol. 95, no. 6 , 7, 1 July 2013 (2013-07-01), pages 20 - 27 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110273550A (zh) * | 2019-05-22 | 2019-09-24 | 中联重科股份有限公司 | 泵送设备的配对自控方法及控制装置 |
Also Published As
Publication number | Publication date |
---|---|
JP2016201579A (ja) | 2016-12-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5816718B2 (ja) | 通信装置、通信システム、およびデータ通信の中継方法 | |
JP5651805B2 (ja) | 通信装置 | |
JP5258938B2 (ja) | 通信装置 | |
JP5521060B2 (ja) | 端末間の通信を高速化する通信装置および通信システム | |
CN101635665B (zh) | 管理隧道的传输信道上的数据流的传送的方法及隧道端点 | |
US8681617B2 (en) | Communication device | |
JP4998687B2 (ja) | 通信システム、トンネリング装置、通信方法、およびプログラム | |
US20090316719A1 (en) | Method for managing mechanisms to enhance transmission of data streams in a tunnel, corresponding computer program product, storage medium and tunnel end-point | |
JP5832335B2 (ja) | 通信装置および通信システム | |
WO2015022809A1 (ja) | 通信装置及び送信帯域制御方法 | |
CA2940077C (en) | Buffer bloat control | |
JP2014135575A (ja) | 通信装置、及び、送信帯域の制御方法 | |
JP5737756B2 (ja) | 通信装置およびパケット廃棄軽減方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14835840 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 14835840 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: JP |