WO2013125096A1 - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
WO2013125096A1
WO2013125096A1 PCT/JP2012/077755 JP2012077755W WO2013125096A1 WO 2013125096 A1 WO2013125096 A1 WO 2013125096A1 JP 2012077755 W JP2012077755 W JP 2012077755W WO 2013125096 A1 WO2013125096 A1 WO 2013125096A1
Authority
WO
WIPO (PCT)
Prior art keywords
band
communication
transmission
tcp
bandwidth
Prior art date
Application number
PCT/JP2012/077755
Other languages
English (en)
French (fr)
Inventor
隆史 磯部
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US14/241,106 priority Critical patent/US9231829B2/en
Priority to CN201280042248.3A priority patent/CN103858404B/zh
Priority to JP2014500864A priority patent/JP5651805B2/ja
Priority to EP12869519.4A priority patent/EP2819353A4/en
Publication of WO2013125096A1 publication Critical patent/WO2013125096A1/ja

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0896Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • H04L47/127Avoiding congestion; Recovering from congestion by using congestion prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/25Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions

Definitions

  • the present invention relates to a communication device, a bandwidth control method, and a communication system, and more particularly to a communication device that controls a communication bandwidth between computers.
  • WAN Wide Area Network
  • IP-VPN Internet Protocol-Virtual Private Network
  • TCP is generally used for communication between terminals.
  • the reception terminal notifies the transmission terminal of the position of the received data with respect to the data transmitted by the transmission terminal.
  • the transmitting terminal determines that the discard is detected.
  • 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. To change the congestion window size.
  • a congestion window size data size that can be transmitted without being notified from the receiving terminal
  • the transmission band greatly depends on the RTT and the discard rate.
  • Patent Document 1 As a method of increasing the window size, there is a technique in which the window size is increased nonlinearly at first, and after a certain threshold value is increased linearly (Patent Document 1).
  • Patent Document 2 in a communication system using TCP in a WAN, a device connected to a receiving terminal sends a feedback notification of all discard points to a device connected to a transmitting terminal;
  • the connected device is provided with means for retransmitting the discarded portion for which feedback notification has been made, and the device connected to the transmitting side terminal is provided with means for controlling the transmission band based on the retransmission band / discarded band.
  • the transmission band is greatly influenced by the RTT and the discard rate. Therefore, in an environment such as WAN where the RTT is large, the number of hops is large, and there are many places where discards occur, the communication band is significantly lower than the contracted band. It may not be obtained.
  • a large communication band can be secured even with a line such as a WAN having a large RTT or a discard rate.
  • an object of the present invention is to provide a communication device that controls a transmission band while allowing other communication using normal TCP to secure a communication band.
  • a first communication device connected to a network, the bandwidth relating to a packet transmitted from the first communication device to the second communication device.
  • the control bandwidth for sending packets in the interval after the current interval is increased for a predetermined period.
  • a transmission unit for sending to the network For each interval, and based on the managed current interval bandwidth and the bandwidth in the past interval, the control bandwidth for sending packets in the interval after the current interval is increased for a predetermined period. Increases the control bandwidth at a first increase rate, and after a predetermined period, increases the control bandwidth at a second increase rate, which is higher than the first increase rate, and sends packets according to the control bandwidth.
  • a transmission unit for sending to the network for sending to the network.
  • FIG. 2 is a block diagram of communication apparatus 200 in the present embodiment.
  • FIG. The block diagram of the proxy part 206.
  • FIG. The block diagram of the TCP part 209.
  • FIG. The block diagram of the TCP part 203.
  • FIG. The format figure of the band table 213.
  • FIG. Explanatory drawing which compares normal TCP and original TCP.
  • FIG. 5B is a flowchart B for updating the control bandwidth using the rate of change of the retransmission rate, the number of connections, and the access bandwidth.
  • FIG. 5B is a flowchart B of a part for increasing the control band. Flowchart diagram C of the portion for increasing the control bandwidth.
  • the conceptual diagram explaining four types of phases of the change of a control band.
  • the conceptual diagram which switches a mode according to the presence or absence of the corresponding
  • the flowchart figure which switches a mode according to the presence or absence of a corresponding
  • the flowchart figure which switches a mode according to the presence or absence of a corresponding
  • the flowchart figure which changes the calculation method of a discard rate / retransmission rate and a resending band according to the presence or absence of an opposing apparatus. Difference between retransmission method of original TCP and normal TCP
  • Example 1 describes a basic form.
  • FIG. 1 shows a configuration diagram of a network system including a communication device.
  • Communication devices also referred to as relay devices, hereinafter simply referred to as devices
  • a router 186 are installed on a communication line that connects the LANs 110, 120, and 130 and the WAN 140 in a plurality of bases.
  • the plurality of computers 111, 112, 113 are connected to the communication apparatus 101 via the LAN 110.
  • the plurality of computers 121, 122, and 123 are connected to the communication device 102 via the LAN 120.
  • the communication devices 101 and 102 and the WAN 140 are connected by access lines 191 and 192.
  • the communication apparatus 101 includes, for example, a transmission band control unit 150 that selects a mode for performing transmission band control by unique TCP as disclosed in Patent Document 2 and performs band control according to the selected mode.
  • the communication apparatus 102 includes an ACK transmission unit 155 necessary for speeding up communication with the communication apparatus 101 via the WAN 140.
  • the first connection is a connection 160 (unique TCP) between the computers 111 and 121 that performs bandwidth control by the transmission bandwidth controller 150.
  • the second connection is a normal TCP connection 163 between the computers 113 and 123 without going through the transmission bandwidth control unit. Note that both the transmission band control unit 150 and the ACK transmission unit 155 may be provided in the communication devices 101 and 102.
  • the router 185 is connected to the computer 134 via a LAN (not shown).
  • the router 185 is connected to the router 186 and the communication device 102 via the WAN 140.
  • the router 186 is connected to a plurality of computers 131, 132, 133 via the LAN 130.
  • a connection 165 from the computer 131 shown in FIG. 1 is a normal TCP connection, and the router 185 performs data communication according to the TCP protocol between the computer 134 and the computer 131 via the WAN.
  • the line 192 may be shared. If the communication apparatus 101 performs control to increase the transmission band rapidly with a connection using a unique TCP, the line band is occupied, and there is a case where communication using a normal TCP connection cannot secure a sufficient communication band. Also in the communication apparatus 101, the unique TCP connection 160 and the normal TCP connection 163 share not only the line 192 but also the line 191. Similarly, between the connections 160 and 163, communication using the connection 163 that is normal TCP cannot secure a sufficient communication band. Therefore, in the following, an example relating to transmission bandwidth control in a connection using a unique TCP will be described in detail so that the communication device 101 or 102 can secure the bandwidth of another connection.
  • the computer includes a server, an information processing device, a terminal, a portable information processing terminal, a smartphone, and the like. Communication between computers includes data transfer between client servers, file transfer between information processing apparatuses, and the like. Further, communication between computers will be described below by taking an example of communication based on a transmission control protocol corresponding to the transport layer of the OSI reference model for Transmission Control Protocol (Transmission Control Protocol, TCP).
  • TCP Transmission Control Protocol
  • the WAN 140 includes a network connecting long bases as compared to the LAN and a network having a large communication delay between the bases.
  • FIG. 2 shows a block diagram of the communication apparatus 200 of the present embodiment. This corresponds to the communication devices 101 and 102 in FIG.
  • the communication 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 non-speed-targeted TCP packet, a non-TCP UDP packet, and an ARP.
  • a filter (202/210) for allowing packets and the like to pass through, a TCP processing unit 203/209 on the WAN side and LAN side for controlling TCP communication, and N transmission buffers 207 managed by the TCP 209 on the WAN side And N reception buffers 208, N transmission buffers 205 and N reception buffers 204 managed by the TCP 203 on the LAN side, and a proxy 206 that exchanges data between the transmission and reception buffers.
  • the communication device 200 includes a memory (not shown).
  • the memory includes a state table (state storage area) 212 including N entries, a bandwidth table 213 including N entries, and each TCP communication.
  • the above-mentioned N pieces may be different numbers.
  • the filter 202/210 determines whether a packet input from the outside is a unique TCP target packet or not, and allows a non-speed-up target TCP packet, a UDP packet (IP protocol number) other than TCP, an ARP packet, and the like to pass through. Let In the case of a TCP packet, it is determined whether or not the TCP packet is a non-target packet by using a combination of an IP address and a port number or one of them. An example is a packet in the connection 163 in FIG. On the other hand, whether the input packet corresponds to a UDP packet other than TCP is determined by the IP protocol number.
  • Whether the input packet is an ARP packet is determined by whether the ether type does not correspond to IPv4 or v6 and whether the ether type is ARP.
  • the packet corresponding to the filter is not subjected to unique TCP processing, the input packet from the LAN side is transferred to the WAN, and the input packet from the WAN side is transferred to the LAN.
  • the TCP processing units 203 and 209 and the proxy 206 will be described in detail later and will be outlined here.
  • the LAN-side TCP processing unit 203 includes a transmission history update unit 725, a packet retransmission unit 724, a reception history update unit 726, a distribution unit 728, and an aggregation unit 732.
  • the reception history update unit 726 accumulates the received packet data in the LAN side reception buffer 204. Further, the reception history update unit 726 updates the information of the buffer management pointers (508 to 510, 515 to 517, and 521 to 527) in the state table 212 according to the accumulated data. Further, the reception history update unit 726 returns an ACK packet describing the position of the received data via the aggregation unit 732.
  • the transmission history update unit 725 transmits the transmission data read from the LAN-side transmission buffer 205 as a packet, and according to the read data, the buffer management pointers (508 to 510, 515 to 517, and 521 to the status table 212). 527) information is updated. Details will be described with reference to FIG. 7B.
  • the WAN TCP processing unit 209 includes a transmission band control unit 715, a transmission history update unit 705, a packet retransmission unit 704, a reception history update unit 706, a distribution unit 708, and an aggregation unit 712.
  • the reception history update unit 706 accumulates the received packet data in the WAN reception buffer 208. Further, the reception history update unit 706 updates the information of the buffer management pointers (508 to 510, 515 to 517, and 521 to 527) in the state table 212 according to the accumulated data. Furthermore, the reception history update unit 706 transmits an ACK packet describing the position of the received data to the other communication device 200 via the aggregation unit 712 and the WAN 140. Details will be described with reference to FIG. 7A.
  • the transmission band control unit 715 stores information on the transmission band, the retransmission band, and the number of ACKs received (number of ACKs received via the WAN 140) in the band table 213.
  • the transmission history update unit 705 transmits the transmission data read from the WAN-side transmission buffer 207 as a packet and transmits the buffer management pointers (508 to 510, 515 to 517, 508) of the state table 212 according to the read transmission data size. 521 to 527) are updated.
  • the proxy 206 includes a data reading unit (601, 606), a data processing unit (602, 605), and a data writing unit (603, 604).
  • the data reading unit (601, 606) updates the information of the buffer management pointers (508 to 510, 515 to 517, and 521 to 527) in the state table 212 according to the data size read from the reception buffer (204, 208). To do.
  • the data writing units (603, 604) store the information of the buffer management pointers (508 to 510, 515 to 517, and 521 to 527) of the state table 212 according to the data size written to the transmission buffer (207, 205). Update. Details will be described with reference to FIG.
  • FIG. 3 is an explanatory diagram of pointers for transmission / reception buffer management. In this figure, data is written from left to right and read from left to right.
  • the reception buffer includes a pointer right_recv 303 indicating the end of the received data, a pointer left_recv 302 indicating the boundary between the aligned data and the unaligned data, and left_rbuf 301 indicating the boundary between the data that the proxy 206 has already read and the data that has not yet been read. , Manage.
  • the pointer right_recv 303 indicating the end 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.
  • the pointer left_recv 302 indicating the boundary between the aligned data and the unaligned data is: Move to the left end of the smallest loss segment.
  • the proxy 206 sequentially reads the data from the left_rbuf 301 indicating the boundary between the read data and the unread data in the right direction, and moves the left_rbuf 301 to the right by the read data size.
  • the maximum data size that can be read is the difference between left_recv 302 and left_rbuf 301.
  • the transmission buffer has received a pointer right_sbuf 306 indicating the end of data that has been written by the proxy 206 and can be transmitted, a pointer right_send 305 indicating the end of data that has already been transmitted, and an acknowledgment from the receiving side.
  • a pointer left_send 304 indicating the end of data is managed.
  • the pointer right_sbuf 306 that indicates the end of data that has been written and transmitted by the proxy 206 increases by the written data size and moves to the right.
  • New data is transmitted to the right starting from the pointer right_send 305 indicating the end of the transmitted data, and the right_send 305 increases by the transmitted data size and moves to the right.
  • left_send 304 increases to the reception sequence number described in the acknowledgment (ACK) packet and moves to the right.
  • FIG. 4 shows a format diagram of a packet transmitted and received by the communication device.
  • the packet includes a MAC header 400, an IP header 410, a TCP header 420, a TCP option header 430, and a payload 450.
  • the MAC header 400 includes a DMAC 401 that represents a destination MAC address, an SMAC 402 that represents a source MAC address, and a Type 403 that represents a MAC frame type.
  • the IP header 410 includes an IP length 411 that represents a packet length excluding the MAC header, a protocol 412 that represents a protocol number, a SIP 413 that represents a source IP address, and a DIP 414 that represents a destination IP address.
  • the TCP header 420 includes a src.
  • the TCP option header 430 includes an option kind 431 indicating an option type, an option length 432 indicating an option length, and a left_edge_1 to 4 (433, 435, 437, 439) and right_edge_1 to 4 (434, 436, 438, 440).
  • the left_edge_1 to 4 (433, 435, 437, 439) and the right_edge_1 to 4 (434, 436, 438, 440) may be used to notify the position of the data portion that could not be received partially.
  • the TCP option header 430 may be used for information exchange between apparatuses when starting TCP communication.
  • the MSS option is used to notify the opposite device of the size of the MSS that can be received by the own device when TCP communication is started.
  • the SACK option is used not only to notify the opposite device that the own device is compatible with the SACK option when starting TCP communication between the communication devices 101 and 102 in FIG. It is also used for notifying the opposite apparatus of a part that can be partially received when discard is detected.
  • 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. 5 shows a format diagram of the state table 212.
  • the state table 212 of the communication apparatus 200 has n entries 520 for recording the state of each TCP connection, for example.
  • Each entry 520 includes, for example, a VLD 501 that describes whether the entry is in use, a connect_state 502 that describes whether a connection on the LAN or WAN side is being established, and the IP address of the computer on the LAN side.
  • LIP 503 representing, WIP 504 representing the IP address of the computer on the WAN side
  • Lport 505 representing the TCP port number of the computer on the LAN side
  • Wport 506 representing the TCP port number of the computer on the WAN side
  • FIG. 6 shows a block diagram of the proxy 206.
  • the proxy 206 includes a data reading unit 601 that reads data from the reception buffer rbuf 204 on the LAN side, and a data processing unit 602 that processes the read data such as compression, decompression, encryption, decryption, deletion, duplication, and appending.
  • a data processing unit 605 that performs processing such as deletion, duplication, and appending, and a data writing unit 604 that writes processed data to the transmission buffer sbuf 205 on the LAN side.
  • Data may be exchanged between the data processing unit 602 and the data processing unit 605.
  • the data processing may be other than the above example.
  • the data reading unit 601 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 508 and lan_left_recv 509.
  • 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 the command data size after prefetching can be estimated.
  • the estimated processed data size is the difference between wan_right_sbuf 526 and wan_left_send 524, that is, the total value of untransmitted data and ACK confirmation wait data does not exceed the WAN transmission buffer size wan_sbuf_size, the data is read and the data processing unit Transfer to 602. Furthermore, the larger one of the estimated data size to be read and the data size after data processing is described in lan_wan 528 of the state table 212.
  • the data reading unit 606 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 515 to wan_left_recv 516.
  • 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.
  • the estimated processed data size is the difference between lan_right_sbuf 523 and lan_left_send 521, that is, the total value of untransmitted data and ACK confirmation wait data does not exceed the LAN transmission buffer size lan_suf_size, the data is read and the data processing unit Transfer to 605. Further, the larger one of the estimated data size to be read and the data size after data processing is described in wan_lan 529 of the state table 212.
  • FIG. 7A shows a block diagram of the TCP processing unit 209 on the WAN side of the communication apparatus 200 of FIG.
  • the TCP processing unit 209 that realizes TCP communication includes an RX unit (reception unit) 702 that performs reception processing and a TX unit (transmission unit) 701 that performs transmission processing.
  • the RX unit 702 is based on a packet distribution unit 708 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.
  • a packet distribution unit 708 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.
  • TCP state (lan_state 507, wan_state 514) in the state table 212, based on the presence / absence of the option number described in the TCP control packet, the mode and the minimum bandwidth specified by the mode / minimum bandwidth specification table 740, A TCP control unit 707 that changes the communication mode (friendly_mode 532, one-way_mode 533) and the minimum bandwidth min_token 534 in the state table 212, the transmission sequence number SEQ423 of the received data packet, and the reception Based on the sequence number ACK424, a reception history update unit 706 returns an ACK packet to change the buffer management pointer in the state table 212.
  • TCP control unit 707 changes the communication mode (friendly_mode 532, one-way_mode 533) at the start of communication based on the presence / absence of the option number described in the TCP control packet will be described later with reference to FIG.
  • TCP control unit 707 changes the communication mode (friendly_mode 532) and the minimum bandwidth min_token 534 at the start of communication based on the mode and minimum bandwidth specified by the mode / minimum bandwidth specification table 740 will be described later with reference to FIG. .
  • the TX unit 701 transmits a TCP control packet using the TCP state lan_state 507 and wan_state 514 in the state table 212, changes the buffer management pointer in the state table 212 based on the received ACK packet, and receives the TCP control packet.
  • the data is read from the transmission buffer sbuf207, and the packet is retransmitted.
  • TCP control packet the retransmission packet
  • the aggregate data packet in FIFO the aggregate data packet in FIFO
  • a multiplexer 712 and a buffer 709 to 711 outputs.
  • the description content of the mode / minimum bandwidth specification table 740 can be changed from the external user terminal 741.
  • blocks for example, a token update unit 717, a multiplexer 712, a buffer 709, etc.
  • a control unit For example, a token update unit 717, a multiplexer 712, a buffer 709, etc.
  • FIG. 7B shows a block diagram of the TCP processing unit 203 on the LAN side in FIG.
  • the TCP processing unit 203 that realizes TCP communication includes an RX unit (reception unit) 722 that performs reception processing and a TX unit (transmission unit) 721 that performs transmission processing.
  • the RX unit 722 includes a packet distribution unit 728 that separates a received packet into a TCP control packet, a packet with data, and an ACK packet, and a TCP that changes the TCP states lan_state 507 and wan_state 514 in the state table 212 based on the received TCP control packet.
  • the control unit 727 Based on the transmission sequence number SEQ 423 and the reception sequence number ACK 424 of the received data packet, the control unit 727 has a reception history update unit 726 that changes the buffer management pointer in the state table 212 and returns an ACK packet.
  • the TX unit 721 changes the buffer management pointer in the state table 212 based on the TCP control unit 723 that transmits the TCP control packet using the TCP state lan_state 507 and wan_state 514 in the state table 212 and the received ACK packet.
  • Packets that read the data from the transmission buffer sbuf205 using the partial acknowledgments left_edge_1 to 4 (433, 435, 436, 439) and right_edge_1 to 4 (434, 436, 438, 440) described in the received ACK packet A retransmission unit 724, a transmission history update unit 725 that transmits a packet with data read from the transmission buffer sbuf 205 and changes a buffer management pointer in the state table 212, and an ACK packet Having DOO, TCP control packet, the retransmission packet, the aggregate data packet FIFO, and a multiplexer 732 and a buffer 729 to 731 outputs.
  • An internal variable called reference time is managed in the transmission bandwidth control unit 715 and the bandwidth table 213 of the WAN side TCP processing unit 209.
  • the interval time is added to the reference time to obtain a new reference time.
  • the reference time before the addition is the old reference time. That is, the reference time used immediately before the currently used reference time becomes the old reference time.
  • a measured average RTT or initial RTT may be used, or a fixed value may be used.
  • the packet with data arriving from the LAN side enters the LAN side TCP processing unit 203 and arrives at the reception history update unit 726.
  • the reception history update unit 726 returns an ACK packet for the packet with data to the LAN side via the aggregation unit 732, and accumulates the data described in the packet in the LAN side reception buffer rubf 204. Further, the reception history update unit 726 updates the pointer of the state table 212 based on the accumulated data size.
  • the data reading unit 601 reads the aligned data stored in the LAN side reception buffer rbuf 204 and transfers it to the data processing unit 602. Further, the pointer of the state table 212 is updated based on the read data size.
  • the data processing unit 602 processes the data and transfers it to the data writing unit 603. Furthermore, the data size being processed in the state table 212 is updated based on the data size being processed.
  • the data writing unit 603 writes the processed data to the WAN side transmission buffer sbuf207. Further, the pointer of the state table 212 is updated based on the written data size.
  • the data written in the WAN side transmission buffer sbuf 207 is read from the transmission history update unit 705.
  • the transmission band control unit 715 performs control to transmit the read data to the WAN side as a packet with data.
  • the reception history update unit 726 will be further described.
  • the remaining amount of the reception buffer is calculated by subtracting the difference between the lan_right_recv 510 and the lan_left_rubf 508 from the maximum value of the reception buffer on the LAN side.
  • the size of the payload 450 is less than or equal to the remaining amount of the reception buffer, all the data described in the payload 450 is stored in the reception buffer.
  • the size of the payload 450 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 450 is stored in the reception buffer.
  • the reception buffer management pointer is updated based on the value of SEQ 423 described in the TCP header 420 of the packet with data and the stored data size. For example, if the value obtained by adding the stored data size to SEQ423 described in the packet header is larger than lan_right_recv510, lan_right_recv510 is changed to the value obtained by adding the stored data size to SEQ423. Further, the received data is described in the reception buffer on the LAN side so that the end of the received data is lan_right_recv510. Thereafter, an ACK packet in which one reception buffer management pointer lan_left_recv 509 is written in ACK 424 of the TCP header 420 is returned to the LAN side.
  • the transmission history update unit 705 will be further described.
  • the data from the wan_right_send 525 to the maximum wan_right_sbuf 526 is read from the WAN side transmission buffer sbuf 207 in the right direction.
  • the wan_right_send 525 increases by the read data size and moves to the right.
  • the read data is described in the payload 450, and a packet with data to which the TCP header 420 in which wan_right_send 525 is described in SEQ423 is added is transmitted to the WAN side. (Variable used to control the transmission bandwidth of data going to the WAN side)
  • the transmission bandwidth control unit 715 uses the variables managed by the bandwidth table 213 to control the transmission bandwidth of data going out to the WAN side of each TCP communication.
  • FIG. 8 shows the format of the bandwidth table 213 managed by the transmission bandwidth control unit 715.
  • the bandwidth table 213 includes, for each connection, a reference time, a transmission bit integrated value / retransmission bit integrated value / ACK reception count / control band after the reference time, and a transmission band / retransmission band / reception band / control band before the reference time. And the transmission band / control band before the old reference time are recorded.
  • the control band after the reference time represents the control band at the current time (in this embodiment, it is expressed as token or token).
  • the transmission band after the reference time represents the transmission band at the current time (in this embodiment, expressed as “snd”), and is obtained by dividing the transmission bit integrated value after the reference time by the difference between the current time and the reference time.
  • the retransmission band after the reference time represents the retransmission band at the current time (in this embodiment, expressed as rts), and is obtained by dividing the retransmission bit integrated value after the reference time by the difference between the current time and the reference time. .
  • the reception band after the reference time represents the reception band at the current time (represented as rcv in this embodiment), and the value obtained by adding the WAN side MSS and 8 to the number of ACKs received after the reference time is the current time and the reference It is obtained by dividing by the time difference.
  • the control band, transmission band, reception band, and retransmission band before the reference time represent the average values of the control band, transmission band, reception band, and retransmission band from the old reference time to the reference time (in this embodiment, old_token, old_snd). , Old_rcv, old_rts).
  • the control band / transmission band before the old reference time represents the control band / transmission band immediately before the old reference time (in the present embodiment, it is represented as old_old_token, old_old_snd).
  • the retransmission rate / discard rate old_rts_ratio before the reference time is obtained by old_rts / old_old_snd or 1-old_rcv / old_old_snd.
  • the current retransmission rate / discard rate rts_ratio after the reference time is obtained by rts / old_snd or 1-rcv / old_snd.
  • a fixed value may be used as the interval time, or wan_rtt 519 described in the state table 212 may be used.
  • FIG. 11 shows the relationship between the old reference time, the reference time, and the current time and the control band, transmission band, reception band, retransmission band, retransmission rate / discard rate before and after that.
  • the difference between the reference time and the old reference time is the interval time.
  • the average values of the control band and transmission band of the interval time before the old reference time are expressed as old_old_token and old_old_snd (1103).
  • the average values of the control band, transmission band, reception band, retransmission band, retransmission rate / discard rate from the old reference time to the reference time are represented as old_token, old_snd, old_rcv, old_rts, and old_rts_ratio (1102).
  • the average values of the control band, transmission band, reception band, retransmission band, retransmission rate / discard rate from the reference time to the current time are expressed as token, snd, rcv, rts, and rts_ratio (1101).
  • the transmission bandwidth control unit 715 calculates the discard rate / retransmission rate (rts_ratio 530 and old_rts_ratio 531) using the above-described values described in the bandwidth table 213.
  • the discard rate / retransmission rate rts_ratio 530 at the current time is calculated as rts / old_token, rts / old_snd, 1-rcv / old_token, or 1-rcv / old_snd.
  • the past discard rate / retransmission rate old_rts_ratio 531 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_rts_ratio 531 and rts_ratio 530), the control band (token or token) is determined and transmitted to the token update unit 717. Further, the state table 212 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 717 manages a token bucket for each TCP connection based on the value of the control band (token or token) transmitted from the transmission band control unit 715 and notifies the multiplexer 712 of a connection that can be transmitted.
  • Control band token update process Details of a method in which the transmission bandwidth control unit 715 updates the control bandwidth (token or token) will be described using the explanatory diagrams of FIGS. 9, 10, and 17 and the flowcharts of FIGS.
  • FIG. 9 is an explanatory diagram of a difference between normal TCP communication and communication using unique TCP, and a method for controlling the transmission bandwidth of unique TCP.
  • the discard rate is obtained by dividing the latest retransmission bandwidth by the transmission bandwidth before RTT, and when the rate of change of the discard rate exceeds a predetermined threshold k, it is determined that congestion has occurred, Based on the transmission band before RTT and the latest retransmission band, the transmission band is reduced (902).
  • the fact that the transmission band has reached the bottleneck band is determined by increasing the change rate of the discard rate. This makes it possible to continue increasing the transmission band until the transmission band reaches the bottleneck band and reaches the top speed without being affected by the stochastic discard.
  • the transmission band is made constant according to the number of received ACKs (903) until the position of the ACK received part is changed.
  • the transmission band is increased gradually (eg, linearly) for a fixed time T (904).
  • the transmission band is continuously increased gradually, for example, linearly, when a certain time T elapses, the method is changed to an abrupt increase method (for example, an exponential non-linear increase method) (905).
  • the period T may be determined by RTT and token (control band), or may be proportional to the product of these.
  • the transmission band control unit 715 includes a first control mode and a second control mode, and the band control is switched to the band control in the second control mode after a predetermined period of time has elapsed in the first control mode. I do.
  • the increase rate of the transmission band in the second control mode may be higher than the increase rate in the first control mode.
  • the certain period T is a predetermined period that can be changed by a management terminal or the like connected to the communication apparatus 200.
  • 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.
  • FIG. 10 is a graph showing time transitions of the transmission band 1001, the discard rate 1002, and the discard rate change rate 1003 on the transmission side of a device performing 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 returning the transmission band to the past transmission band
  • Phase 4 is a step of making the transmission band constant.
  • the transmission bandwidth increases in phase 1 (1004), and at some point exceeds the bottleneck bandwidth (1013).
  • packet discard occurs, but it takes RTT or more until the discard location is notified from the reception side to the transmission side. Therefore, the fact that the transmission band exceeds the bottleneck band will appear as an increase in the discard rate after RTT (1014).
  • the discard rate is obtained by dividing the most recent retransmission band by the transmission band before RTT. As long as the transmission band is smaller than the bottleneck band, only the probabilistic discard occurs, so the discard rate is constant (1010).
  • discard due to overuse (1011) is added in addition to stochastic discard, and the discard rate starts to increase (1012).
  • the change rate of the discard rate increases rapidly from 1 and exceeds the threshold value k (1009).
  • a value obtained by subtracting the current retransmission bandwidth from the transmission bandwidth before RTT is set as a new transmission bandwidth (1018).
  • 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 of the discard rate continues for a while (1012), the transmission band continues to decrease during that time.
  • the step of reducing the transmission band is phase 2 (1005).
  • the discard rate starts to decrease (1019).
  • the change rate of the discard rate becomes smaller than 1 and falls below the threshold value k (1020), it is determined that congestion has not occurred in the network.
  • the transmission band control unit 715 gradually increases the transmission band, for example, in the first control mode (1007). If no congestion is detected for a certain period T, then the transmission band control unit 715 increases the transmission band rapidly (for example, non-linearly) in the second control mode (1008). When increasing non-linearly, it may be increased exponentially, such as multiplying by ⁇ E every RTT (1016). The period T during which the initial transmission band is increased slowly (for example, linearly) may be determined by the RTT and the token (token: control band), or may be proportional to the product of these (1021). . While the initial transmission band is slowly increased (for example, linearly), 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 (1017).
  • 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.
  • transmission is performed until the transmission bandwidth reaches the bottleneck bandwidth and reaches the top speed without being affected by stochastic discard. It becomes possible to continue to increase the bandwidth, and the line bandwidth can be used up.
  • 12 to 16 are flowcharts for explaining the details of the method in which the transmission band control unit 715 updates the control band (token or token).
  • FIG. 12 to 15 show details of bandwidth control in the original TCP
  • FIG. 16 shows details of a bandwidth increase method for protecting normal TCP communication without communication by the original TCP occupying the line bandwidth. Indicates.
  • FIG. 12A shows a conceptual flowchart when the transmission bandwidth control unit 715 updates the control bandwidth (token or token).
  • the transmission bandwidth control unit 715 executes processing according to this flowchart, thereby realizing bandwidth control based on the retransmission rate, and can use up the line bandwidth independently of the RTT and the discard rate.
  • Each step in FIG. 12A is executed by the transmission band control unit 715.
  • the increase rate of the packet retransmission rate exceeds a predetermined threshold, the current retransmission band (rts) and the past control band (old_token) (old before the reference time) or the past (prior to the reference time)
  • the control band (token) is updated using the transmission band (old_snd) (step 1203).
  • the control band in the past (before the reference time) is reduced by an amount corresponding to the current retransmission band to obtain the control band at the current time.
  • the transmission band control unit 715 increases the control band (step 1204).
  • the transmission band control unit 715 updates the control band (token) based on the minimum band (min_token 534) of each connection (step 1206). By changing the control band (token), the amount of tokens accumulated in the token bucket is changed, thereby making it possible to change the packet transmission rate.
  • FIG. 12B shows a flowchart in which the transmission bandwidth control unit 715 changes the control bandwidth (token) using the values described in the bandwidth table 213.
  • FIG. 12A is shown in more detail is shown.
  • Each step of FIG. 12B is executed by the transmission band control unit 715.
  • the transmission bandwidth control unit 715 executes processing according to this flowchart, thereby realizing bandwidth control based on the retransmission rate, and can use up the line bandwidth independently of the RTT and the discard rate.
  • the transmission band control unit 715 When the update process of the control band (token) starts (step 1207), the transmission band control unit 715 outputs the difference between the current time output from the timer 713 and the reference time described in the band table 213 as the output of the interval storage unit 714. It is determined whether or not the interval time is over (step 1208). As the interval time, wan_rtt 519 or the like of the state table 212 in which the measured average value or initial value of the RTT is recorded may be used. If it is determined to be true in step 1208, the value of the current control band token after the reference time is saved in tmp (step 1209).
  • the retransmission rate (after the reference time) rts_ratio obtained by the retransmission bit integrated value (after the reference time) / (current time ⁇ reference time) / transmission band (before the reference time) stored in the band table 213 is retransmitted. It is determined whether or not the old retransmission rate (before the reference time) old_rts_ratio obtained by the band (before the reference time) / the transmission band (before the old reference time) is greater than K times (K: a predetermined coefficient of 1 or more). (Step 1210). Step 1210 corresponds to step 1202 described above.
  • the value of K may be fixed or may vary depending on the value of token.
  • control band (after reference time) token control band (before reference time) old_token-retransmission band (after reference time) rts, etc. (step 1212).
  • Step 1212 corresponds to step 1203 described above. If it is determined to be false in step 1210, the control band (after the reference time) is increased (step 1211).
  • the method of increasing the control band (after the reference time) token may be increased linearly, may be increased exponentially, or a combination of linear increase and exponent increase may be used.
  • the index may be increased at the same time, or the rate of increase may be changed according to the control band (after the reference time) token.
  • Step 1211 corresponds to 1204 described above.
  • transmission band (before the reference time) old_snd transmission band (after the reference time) snd
  • retransmission band ( Before reference time) old_rts retransmission band (after reference time) rts
  • reference time reference time + interval
  • control band (before reference time) old_token tmp
  • control band at the time of periodic update c_token new control band token, etc. Record in the table 213 and the status table 212 -Up 1213). Thereafter, the process proceeds to step 1217.
  • K one or more predetermined coefficients
  • control band (after the reference time) token is set to the control band (before the reference time) old_token as in step 1212. For example, it is decreased by using the retransmission band rts so as to be smaller than the value.
  • control band (after reference time) token control band (before reference time) old_token-retransmission band (after reference time) rts, etc. (step 1215). If it is determined in step 1214 that it is small or equivalent, nothing is done. By these steps, even if the interval time does not elapse, network congestion can be immediately detected from the increase in the retransmission rate, and the control band can be updated. After these steps, go to step 1217.
  • step 1217 if the control bandwidth (after the reference time) token is smaller than the minimum bandwidth min_token of each TCP communication, the control bandwidth (after the reference time) token is changed to the minimum bandwidth min_token 534 of each TCP communication (step 1217). . That is, the smaller of the tokens determined by the two expressions shown in step 1217 of FIG. 12B is taken. Note that data such as token and min_token 534 in step 1217 can be read with reference to the state table 212 and the bandwidth table 213. By changing the control band (token), the amount of tokens accumulated in the token bucket is changed, thereby making it possible to change the packet transmission rate.
  • the bandwidth control based on the discard rate or the retransmission rate is performed as in the flowchart described with reference to FIG.
  • the transmission band can be increased until the bottleneck band is reached and the top speed is reached.
  • the original TCP can use up the line bandwidth without depending on the RTT and the discard rate.
  • FIGS. 13, 14, and 15 are flowcharts in which the transmission band control unit 715 changes the control band (token) using the values described in the band table 213.
  • Each step of FIGS. 13, 14, and 15 is executed by the transmission band control unit 715.
  • the transmission bandwidth control unit 715 executes processing according to this flowchart, thereby realizing bandwidth control based on the retransmission rate, and can use up the line bandwidth independently of the RTT and the discard rate.
  • FIG. 13 shows a main flowchart in which the transmission band control unit 715 changes the control band (token) using the values described in the band table 213.
  • the transmission bandwidth control unit 715 first calculates the discard rate (1301).
  • the discard rate is calculated as rts / old_token, rts / old_snd, 1-rcv / old_token, or 1-rcv / old_snd, as described above with reference to FIG.
  • a retransmission rate may be used as the discard rate.
  • the threshold value k is adjusted according to the token value (1302). When the token value is large, by reducing the threshold value k, even if the discard rate is slightly increased, the change rate of the discard rate is likely to exceed the threshold value k, and network congestion is easily detected.
  • it is determined whether or not RTT has elapsed since the last periodic update (step 1303).
  • step 1208 This is a process corresponding to step 1208 for determining whether or not the difference between the current time and the reference time is greater than or equal to the interval. If the RTT has elapsed, a periodic update process is performed for each RTT (1304). If the RTT has not elapsed, an irregular update process is performed (1305). Details of the periodic update 1304 and the irregular update 1305 will be described later with reference to FIGS. 14 and 15, respectively.
  • processing for updating the control band (token) is performed based on the number of active connections and the access band (1306). This process ensures fairness between connections. Further, the control band (token) is updated based on the minimum band min_token 534 of each TCP connection communication (step 1307).
  • FIG. 14 shows a detailed flowchart of the control band (token) periodic update process 1304 performed by the transmission band control unit 715.
  • the transmission band control unit 715 is based on the retransmission band rts before 0 to RTT and the transmission band old_snd or control band old_token before RTT to 2RTT.
  • step 1402 is referred to as phase 2.
  • the current ACK received part wan_left_send 524 is compared with the value of old_wan_left_send 527 indicating the part of the ACK received before RTT (step 1403), and if it has changed, the periodic update 1304 for each RTT is terminated. If not, the process proceeds to step 1405.
  • the transmission bandwidth control unit 715 sets the current ACK received part wan_left_send 524 and old_wan_left_send 527 indicating the ACK received part before RTT. The values are compared (step 1404). If not, the process proceeds to step 1405. In step 1405, the transmission band control unit 715 refers to the WAN transmission buffer 207 and determines whether there is untransmitted data (step 1405). If there is untransmitted data in the transmission buffer 207, the transmission band control unit 715 adjusts the control band based on the number of ACK received before 0 to RTT (step 1406).
  • the transmission band control unit 715 ends the regular update 1304 for each RTT.
  • the control band (token) is increased (step 1407).
  • the processing in step 1407 is referred to as phase 1.
  • the periodic update 1304 for each RTT ends. Details of step 1407 for increasing the control band (token) will be described later with reference to FIG.
  • FIG. 15 shows a detailed flowchart of the control band (token) irregular update processing 1305 performed by the transmission band control unit 715.
  • step 1303 in FIG. 13 if the RTT has not elapsed since the previous control band update process for each RTT in step 1304, the irregular update process 1305 performed by the transmission band control unit 715 starts with a discard rate ( It is determined whether or not the increase rate of (rts_ratio) exceeds the threshold value k (step 1501). When the increase rate of the discard rate (rts_ratio) exceeds the threshold k, a new control band is determined based on the retransmission band rts before 0 to RTT and the transmission band old_snd or control band old_token before RTT to 2RTT. (Step 1502).
  • a new control band token control band (before reference time: before RTT to 2 RTT) old_token ⁇ retransmission band (after reference time: 0 to before RTT) rts, etc. (step 1502).
  • step 1502 is referred to as phase 2 as with step 1402.
  • the irregular update processing 1305 ends.
  • the control band (token) is updated using the control band (c_token) at the time of the latest periodic update ( Step 1503).
  • token c_token. (Step 1503).
  • step 1503 is referred to as phase 3.
  • the update process of the control band (token) performed by the transmission band control unit 715 is broadly divided into phase 1 (step 1407) for increasing the band and decreasing the band.
  • Phase 2 step 1402, step 1502
  • phase 3 step 1503
  • phase 4 step 1406 for making the bandwidth constant according to the number of received ACKs. Is done.
  • FIG. 17 is a graph showing how the control band (token) changes in chronological order by the update process of the control band (token) performed by the transmission band control unit 715.
  • phase 1 for increasing the bandwidth
  • phase 2 step 1402, step 1502
  • phase for making the bandwidth constant according to the number of received ACKs. 4 step 1406
  • Phase 3 for returning the bandwidth to the original value is a phase when the control bandwidth (token) is constant until the periodic update for each RTT.
  • the transmission bandwidth control unit 715 updates the bandwidth increase start time inc_time 538 of the state table 212 with the current time during Phase 2 and Phase 4. Further, in phase 4, t_token 535 in state table 212 is updated with the current control band (token). t_token 535 corresponds to the bottleneck band detected by the original TCP.
  • FIG. 16A shows a flowchart of the bandwidth increase processing in step 1407.
  • the transmission bandwidth control unit 715 In the bandwidth increase processing 1407 performed by the transmission bandwidth control unit 715, first, the value of friendly_mode 532 described in the state table 212 is checked, and in a mode friendly to normal TCP, that is, in the first control mode. Determine whether the communication is valid. In addition, it is determined whether or not the difference between the current time and the band increase start time inc_time 538 has exceeded the time T (step 1601). When the friendly mode friendly_mode 532 is valid and the difference between the current time and the band increase start time inc_time 538 does not exceed the time T, the transmission band control unit 715 slowly sets the band in the first control mode. Increase (step 1603).
  • the coefficient ⁇ L is, for example, less than 1.
  • the transmission band control unit 715 has a higher transmission band increase rate than the first control mode.
  • the bandwidth is rapidly increased (step 1602).
  • a new control band (token) coefficient ⁇ E ⁇ original control band (token) is set (step 1602).
  • the congestion rate of the network is not detected, for example, the increase rate of the discard rate does not exceed the threshold value k (step 1401), and the data portion whose reception has been confirmed is being updated (step 1404).
  • the transmission band is increased slowly, for example, linearly (step 1603), and then the transmission band is increased rapidly, for example, nonlinearly (step 1602).
  • communication using the original TCP is prevented from occupying the line bandwidth, and communication using the normal TCP can secure the communication bandwidth.
  • FIG. 16B shows another flowchart of the bandwidth increase processing in step 1407.
  • FIG. 16A shows an example in which one branch process is added.
  • a branch process (step 1604) is newly added between step 1601 and step 1602 described using FIG. 16A, and a flow for executing a process (step 1605) different from step 1602 is added. Other than that is the same as FIG. 16A.
  • the measured RTT exceeds a certain multiple (for example, twice) of the initial RTT, a process for making the bandwidth increase rate equal to that of the normal TCP is added. Even if network congestion has not been detected, it is possible to prevent excessive use of the line bandwidth by reducing the bandwidth increase rate at an early stage when the RTT starts to increase, and the bandwidth can be used fairly.
  • FIG. 16C shows another flowchart of the bandwidth increase processing in step 1407.
  • FIG. 16B shows an example in which one branch process is added.
  • a branch process (step 1615) is newly added between step 1604 and step 1602 described using FIG. 16B, and a flow for executing a process different from step 1602 (step 1616) is added. Other than that is the same as FIG. 16B.
  • a certain multiple for example, twice
  • the transmission band control unit 150 of the communication device 101 and the transmission band control unit 715 of the communication device 200 corresponding to the communication device 101 of FIG. 1 are equipped with the first to fourth control modes, as shown in FIGS. Any one of the processes may be executed.
  • or 4th control modes were mounted or set in the state which can be performed may be sufficient.
  • the transmission band control unit 715 (150 in FIG. 1) may be changed to another control mode under the conditions of FIG.
  • Each control mode may be stored as a program in the nonvolatile storage medium of the communication device 200.
  • two or more control modes may be set to a state in which the communication apparatus can be executed from the management terminal or the like.
  • transmission bandwidth control is performed to increase or decrease the increase rate according to a predetermined condition, and fair use of bandwidth with other communications is achieved. Also, the determination of whether or not “friendly mode is valid” 1601 in FIGS. 16A to 16C may be omitted.
  • the control mode for increasing the transmission band performed by the transmission band control unit 715 has been described above.
  • the communication mode (friendly mode friendly_mode 532 or one-way mode one) described by the TCP control unit 707/703 in the state table 212 using the sequence diagram of FIG. 18, the flowcharts of FIGS. 19 to 20, and the table format diagram of FIG. Details of the method of determining -way_mode 533) will be described.
  • the mode / minimum bandwidth designation table 740 includes a plurality of entries that specify the validity / invalidity of the friendly mode and the minimum bandwidth for each combination of transmission IP / subnet, destination IP / subnet, transmission port, and destination port.
  • the user terminal 741 shown in FIG. 7A designates whether the friendly mode is valid or invalid and the minimum bandwidth for each combination of transmission IP / subnet, destination IP / subnet, transmission port, and destination port.
  • the destination IP / subnet, the transmission port, and the destination port an item having an arbitrary value is designated as Any. If you want to specify the default operation for any combination, specify all of the transmission IP / subnet, destination IP / subnet, transmission port, and destination port as Any, then enable / disable friendly mode and specify the minimum bandwidth do it.
  • the destination IP / subnet, and other transmission IP / subnet, transmission port and destination port are set to Any, etc.
  • Enable / disable friendly mode and specify minimum bandwidth For communication of a specific transmission port number of a specific network source, when it is desired to specify whether the friendly mode is enabled or disabled and the minimum bandwidth is specified, the destination IP / subnet and the destination port are set to Any, etc. Specify the transmission port, enable / disable friendly mode, and minimum bandwidth.
  • the TCP control unit 707/703 When the TCP control unit 707/703 receives a SYN packet or a SYNACK packet and establishes a connection, the TCP control unit 707/703 searches the mode / minimum bandwidth specification table 740 for a matching entry from above, and if there is a matching entry, The specified minimum bandwidth is described in min_token 535 of the state table 212. Further, the transmission band control unit 715 controls the control band (token) so as not to fall below the min_token 535 based on the min_token 535 in the state table 212. Thereby, the minimum bandwidth of each TCP communication can be determined in advance from the outside.
  • FIG. 18A shows a sequence diagram for determining a communication mode when a communication device (unique TCP compatible) that spontaneously starts communication determines that the opposite device is unique TCP compatible.
  • the communication device 1801 (compatible with TCP) transmits a SYN packet 1803 having a unique option number to the opposite communication device (compatible with TCP) 1802.
  • the opposite communication device (unique TCP compatible) 1802 returns a SYNACK packet 1804 having a unique option number.
  • communication apparatus 1801 (unique TCP compatible) receives SYNACK packet 1804 having a unique option number from the opposite communication apparatus (unique TCP compatible) 1802, transmission described in IP header 410 and TCP header 420 of SYNACK packet 1804 Using the IP address 413, the destination IP address 414, the transmission port number 421, and the reception port number 422, a matching entry is searched from the top in the mode / lowest bandwidth designation table 740. If there is a matching friendly mode valid entry, the friendly mode 532 of the status table 212 is validated (1805).
  • FIG. 18B shows a sequence diagram for determining the communication mode when the communication device (unique TCP compatible) that spontaneously starts communication determines that the opposite device does not support the unique TCP.
  • the communication device 1801 (compatible with unique TCP) transmits a SYN packet 1803 having a unique option number to the opposite device (not compatible with unique TCP) 1806.
  • the opposite device (not supporting the unique TCP) 1806 returns a SYNACK packet 1807 having no unique option number.
  • the communication apparatus 1801 (unique TCP compatible) receives a SYNACK packet 1807 having no unique option number from the opposite apparatus (non-proprietary TCP compatible) 1806, the communication apparatus 1801 enables the one-way_mode 533 and the friendly mode 532 of the state table 212. (1808).
  • FIG. 18C shows a sequence diagram for determining the communication mode when the communication device that passively starts communication (unique TCP compatible) when the opposite device is unique TCP compatible.
  • the communication device 1801 (compatible with TCP) receives a SYN packet 1809 having a unique option number from the opposite communication device (compatible with TCP) 1802, it returns a SYNACK packet 1810 with a unique option number. Further, a matching entry from the mode / minimum bandwidth specification table 740 using the transmission IP address 413, the destination IP address 414, the transmission port number 421, and the reception port number 422 described in the IP header 410 and the TCP header 420 of the SYN packet 1809. Search from above. If there is a matching friendly mode valid entry, the friendly mode 532 of the status table 212 is validated (1811).
  • FIG. 18D shows a sequence diagram for determining a communication mode when a communication device (unique TCP compatible) that passively starts communication determines that the opposite device does not support unique TCP.
  • the communication device 1801 When the communication device 1801 (corresponding to the unique TCP) receives the SYN packet 1812 having no unique option number from the opposite device (not supporting the unique TCP) 1806, it returns a SYNACK packet 1813 not having the unique option number. Further, the one-way_mode 533 and the friendly mode 532 of the state table 212 are validated (1814).
  • the opposing device that does not support unique TCP is, for example, a communication device such as the router 186 in FIG.
  • FIG. 19 is a flowchart showing a communication apparatus that spontaneously starts communication corresponding to FIGS. 18A to 18D and determines the communication mode.
  • the TCP control unit 703 When the communication device 1801 (compatible with unique TCP) spontaneously starts communication (step 1901), the TCP control unit 703 first transmits a SYN packet having a specific option number (step 1902). When a SYNACK packet is received from the opposite device (step 1903), the TCP control unit 703/707 next determines whether the SYNACK packet has a specific option number (step 1904). When there is a specific option number, the mode / minimum bandwidth is specified using the transmission IP address 413, the destination IP address 414, the transmission port number 421, and the reception port number 422 described in the IP header 410 and the TCP header 420 of the SYNACK packet. A matching entry is searched from the table 740 to determine whether there is a matching friendly mode valid entry (step 1906).
  • the TCP control unit 703/707 establishes communication as it is (step 1908). If there is a matching friendly mode valid entry, the friendly mode 532 of the status table 212 is validated (step 1907). If there is no specific option number in step 1904, the one-way_mode 533 of the state table 212 is validated (step 1905). Thereafter, the friendly mode may be forcibly enabled (step 1907), or step 1906 may be performed to enable / disable the friendly mode 532 of the status table 212 based on the search result of the mode / minimum bandwidth specification table 740. You may decide invalidity. Note that the friendly mode 532 and the one-way_mode 533 of the state table 212 are disabled by default. As a result, a communication apparatus that predetermines TCP communication to which the transmission bandwidth increasing method is applied from the outside is realized.
  • FIG. 20 is a flowchart for determining a communication mode by a device that passively starts communication.
  • the communication device 1801 When the communication device 1801 (corresponding to the unique TCP) passively starts communication (step 2001), it first receives a SYN packet (step 2002) and starts communication (step 2003). Next, it is determined whether or not the SYN packet has a specific option number (step 2004). When there is a specific option number, the mode / minimum bandwidth is specified using the transmission IP address 413, the destination IP address 414, the transmission port number 421, and the reception port number 422 described in the IP header 410 and the TCP header 420 of the SYN packet. A matching entry is searched from the table 740 from above, and it is determined whether there is a matching friendly mode valid entry (step 2006). If there is a matching friendly mode valid entry, the friendly mode 532 of the status table 212 is validated (step 2007).
  • step 2004 If there is no specific option number in step 2004, the one-way_mode 533 of the state table 212 is validated (step 2005). Thereafter, the friendly mode may be forcibly enabled (step 2007), and step 2006 is executed, and based on the search result of the mode / minimum bandwidth specification table 740, the friendly mode 532 of the status table 212 is enabled / disabled. You may decide invalidity. Note that the friendly mode 532 and the one-way_mode 533 of the state table 212 are disabled by default.
  • step 2008 it is next determined whether or not the one-way_mode 533 is valid (step 2008). When the one-way_mode 533 is valid, a SYNACK packet having a specific option number is transmitted to the opposite apparatus (step 2009).
  • a SYNACK packet having no specific option number is transmitted to the opposite device (step 2010).
  • communication is established (step 2011).
  • a communication apparatus that predetermines TCP communication to which the transmission bandwidth increasing method is applied from the outside is realized.
  • the table format shown in FIG. 23, the sequence shown in FIG. 18, and the flowcharts shown in FIGS. Can be specified. Furthermore, the friendly mode can be forcibly applied when option information having a specific value is not sent from the opposite device at the start of TCP communication. (Change the discard rate calculation method according to the communication mode)
  • the details of the discard rate calculation process performed by the transmission bandwidth control unit 715 in accordance with the communication mode will be described with reference to the flowchart of FIG. 21 and the sequence diagram of FIG.
  • FIG. 22 is a sequence diagram for explaining the difference in retransmission method when a packet discard between the original TCP and the normal TCP occurs.
  • the normal TCP retransmission control method is shown on the left side, and the original TCP retransmission control method is shown on the right side.
  • the left_edge_1 to 4 (433, 435, 437, 439) and the right_edge_1 to 4 (434, 436, 438, 440) in the TCP option header 430 of the ACK packet are partially received from where to where. These are used for partial acknowledgment (Selective ACK (SACK)).
  • SACK Selective ACK
  • the left_edge_1 to 4 (433, 435, 437, 439) and the right_edge_1 to 4 (434, 436, 438, 440) in the TCP option header 430 should be partially retransmitted from where to where. Are used for partial unacknowledged responses (Negative ACK (NACK)).
  • the TCP option header 430 is displayed. Due to the restriction that the maximum number of received parts that can be written is four, an acknowledgment response to a packet sent after I cannot be sent to the transmission computer 2201 at this point (2209).
  • the transmission computer retransmits the discarded packets B, D, F, and H among the packets A to I using the acknowledgment packet (2209) in which the partial acknowledgments from A to I are described (2206).
  • the receiving computer 2202 After receiving the retransmission packet (2206), the receiving computer 2202 returns a confirmation response describing a partial confirmation response after the packet I (2212).
  • the transmission computer 2201 can retransmit the packet J discarded after the packet I after receiving the confirmation response (2212) describing the partial confirmation response after the packet I (2207).
  • a to L (2208) sent from the transmission computer 2203 to the reception computer 2204 A to The part to be retransmitted up to J is written to left_edge_1 (433) and right_edge_1 (434) in the TCP option header 430 one by one, and then an ACK packet for partial unconfirmed response (NACK) is returned (2211).
  • NACK ACK packet for partial unconfirmed response
  • the transmission computer 2203 Upon receiving the partially unacknowledged response (NACK) ACK packet (2211), the transmission computer 2203 retransmits the retransmission request portions B, D, F, H, and J described in the TCP option header 430 (2210). Even when a large amount of loss occurs, since retransmission is completed at once, the communication time is shortened and the bandwidth is improved. In other words, two communication relay devices (proxy devices) are installed between the transmission computer and the reception computer, and the proxy device on the reception computer side notifies the proxy device on the transmission computer side of all the discard points in a feedback manner.
  • proxy devices two communication relay devices
  • the proxy device on the transmission computer side resends the discarded portion notified of feedback from the proxy device on the reception computer side, and based on the retransmission band and the discard band after the reference time and the transmission band before the reference time, Increase or decrease the sum of the data transmission bandwidth and data retransmission bandwidth for a specific destination. Thereby, communication independent of the discard rate can be realized.
  • FIG. 21 shows a flowchart for changing the discard rate calculation method according to the communication mode.
  • the one-way_mode 533 of the state table 212 is valid (step 2101). If the one-way_mode 533 is invalid, it means that the opposite device supports the original TCP, so the most recent retransmission number and the transmission number before RTT, or the most recent retransmission band rts and the control band old_token before RTT are used. Then, the retransmission rate is calculated and used as the discard rate (step 2105). On the other hand, if the one-way_mode 533 is valid, it is determined whether or not a duplicate ACK is being received (step 2102). If no duplicate ACK has been received, the discard rate is set to 0 (step 2103).
  • the discard rate is calculated using the latest number of ACKs received and the number of transmissions before RTT, or the latest reception band rcv and control band old_token before RTT (step 2104). As a result, only when the option information having a specific value is not sent from the opposite device, the discard rate is estimated using the history of the transmission band and the number of received ACKs, and the transmission band control unit that performs the band control based on the estimation result Is realized.
  • the communication device in the present embodiment when option information having a specific value is not sent from the opposite device at the start of TCP communication, that is, when the opposite device does not support unique TCP, By estimating the discard rate using the history of the transmission band and the number of received ACKs, the discard rate is estimated without using NACK. Thereby, the error of the discard rate used by the original TCP for bandwidth control can be reduced, and the above-described bottleneck bandwidth can be easily estimated.
  • the unique TCP compatible communication device of the second embodiment may be a communication device based on the configuration of the first embodiment.
  • Other aspects disclosed in the present specification, such as the above-described embodiments, are as follows.
  • the communication device that controls the transmission band of TCP communication does not detect congestion in the TCP communication, and the transmission band of the TCP communication is linear for a certain period after the data portion that has been confirmed to be received is being updated.
  • Means for increasing the transmission rate means for increasing the transmission band in a non-linear manner after the fixed period has passed, and means for detecting congestion using the rate of change of the discard rate or retransmission rate in the TCP communication, Means for estimating the retransmission rate and its rate of change using the past history of the transmission band and retransmission band; and means for estimating the discard rate and its rate of change using the past history of the transmission band and the number of received ACKs; Means for reducing the transmission band using the past history of the transmission band, the retransmission band, and the number of received ACKs when congestion is detected.
  • a communication device that relays a plurality of TCP communications on the LAN side and the WAN side, a bandwidth control unit that controls the transmission bandwidth of each TCP communication, a status table that records a history of data locations that have been confirmed to be received for each TCP communication, A bandwidth table that records a past history of a transmission bandwidth, a control bandwidth, a reception bandwidth, and a retransmission bandwidth in each TCP communication, and the bandwidth control unit includes a transmission bandwidth, a control bandwidth, and a reception bandwidth described in the state table. Based on the past history of retransmission bandwidth and the history of the received data location described in the status table, it is determined whether there is congestion in the TCP communication and whether the received data location is being updated. For a certain period after the data location that has been confirmed to be received is being updated, the transmission bandwidth of the TCP communication is linearly increased, and after the certain period has passed, the TCP communication Communication device to increase the transmission bandwidth nonlinearly is provided.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

 WANのようなRTTが大きく、ホップ数が大きく廃棄発生箇所が多い環境において、大きなスループットを得られる独自TCPによる通信が、通常のTCPによる通信と競合しても、回線帯域を占有することを防ぐ。TCP通信の送信帯域を制御する通信装置が、前記TCP通信において輻輳が検出されず、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させる手段と、前記の一定の期間が過ぎた後、送信帯域を非線形的に増加させる手段と、前記TCP通信において、廃棄率や再送率の変化率を用いて輻輳を検出する手段と、送信帯域と再送帯域の過去の履歴を用いて再送率とその変化率を推定する手段と、送信帯域とACK受信数の過去の履歴を用いて廃棄率とその変化率を推定する手段を備える。

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が大きいほど、廃棄率が大きいほど、ウィンドウサイズが増加しにくくなり、帯域が小さくなる。
 以上のように、WANにおけるTCPを用いた通信では、送信帯域がRTTと廃棄率に大きく左右される。
 ウィンドウサイズを増加させる方法として、最初は非線形に増加させていき、ある閾値を上回った後は、線形に増加させていく技術もある(特許文献1)。
 一方、特許文献2は、WANにおけるTCPを用いた通信システムにおいて、受信側端末に接続した装置が、送信側端末に接続した装置に対して廃棄箇所を全てフィードバック通知する手段と、送信側端末に接続した装置がフィードバック通知された廃棄箇所を再送する手段と、送信側端末に接続した装置が再送帯域・廃棄帯域に基づいて送信帯域を制御する手段を備える。
WO2007/092901号 WO2011/033894号
 TCPを用いた通信では、送信帯域がRTTと廃棄率に大きく左右されるため、WANのようなRTTが大きく、ホップ数が大きく廃棄発生箇所が多い環境で、契約帯域を大幅に下回る通信帯域しか得られない場合がある。
 また、特許文献2では、RTTや廃棄率が大きいWANのような回線でも、大きな通信帯域を確保することができる。
 ところが、通常のTCPを用いた通信と、特許文献2のような帯域制御を行う通信が、同一の通信回線を共有する場合、特許文献2による通信のように、回線帯域を占有してしまい、通常のTCPを用いた通信が通信帯域を確保できないケースがあった。
 本発明は、以上の点に鑑み、通常のTCPを用いた他の通信が、通信帯域を確保できるようにしつつ、送信帯域を制御する通信装置を提供することを目的とする。
 上記課題を少なくとも一を解決するために、本願発明の一態様では、ネットワークに接続される第一の通信装置であって、第一の通信装置から第二の通信装置に送信されるパケットに関する帯域をインターバル毎に管理し、管理される現在のインターバルの帯域及び過去のインターバルにおける帯域に基づいて、現在のインターバルよりも後のインターバルにおけるパケットを送出するための制御帯域を増加させる場合、所定の期間は、第一の増加率で制御帯域を増加させ、所定の期間経過後は、第一の増加率よりも高い、第二の増加率で前記制御帯域を増加させ、その制御帯域に従って、パケットをネットワークに送出する送信部と、を有する。
 本発明によると、同一の通信回線を複数の通信で共有する場合でも、一の通信における帯域制御による回線での回線帯域を占有することを防ぎ、複数の通信が通信帯域を確保することができ、公平な帯域の利用となる。
本実施の形態における通信装置を含むネットワークシステムの構成図。 本実施の形態における通信装置200のブロック図。 バッファのポインタの説明図。 パケットのフォーマット図。 状態テーブル212のフォーマット図。 プロキシ部206のブロック図。 TCP部209のブロック図。 TCP部203のブロック図。 帯域テーブル213のフォーマット図。 通常TCPと独自TCPを比較する説明図。 廃棄率の変化率を用いた輻輳制御の説明図。 シェーパ毎の帯域テーブル213が保持する値の意味を説明する概念図。 再送率の変化率と、コネクション数とアクセス帯域を用いて制御帯域を更新するフローチャート図A。 再送率の変化率と、コネクション数とアクセス帯域を用いて制御帯域を更新するフローチャート図B。 制御帯域を更新する上位のフローチャート図。 RTT毎に制御帯域を定期更新する部分のフローチャート図。 制御帯域を不定期更新する部分のフローチャート図。 制御帯域を増加させる部分のフローチャート図A。 制御帯域を増加させる部分のフローチャート図B。 制御帯域を増加させる部分のフローチャート図C。 制御帯域の変化の4種類のフェーズを説明する概念図。 対向装置の独自TCPへの対応の有無に応じてモードを切り替える概念図。 対向装置の独自TCPへの対応の有無に応じてモードを切り替えるフローチャート図。 対向装置の独自TCPへの対応の有無に応じてモードを切り替えるフローチャート図。 対向装置の有無に応じて廃棄率/再送率と再送帯域の計算方法を変更するフローチャート図。 独自TCPと通常TCPの再送方法の差異 モード/最低帯域指定テーブルのフォーマット図。
 本発明を実施するための代表的な形態は、下記の通りである。実施例1には基本的な一形態を、記載する。
 まず、図1を用いて、本発明が解決しようとする課題について説明する。
 図1は、通信装置を含むネットワークシステムの構成図を示す。
  通信装置(中継装置ともいう。以下、単に装置と記す)101、102及びルータ186は、複数の拠点内のLAN110、120、130とWAN140を接続する通信回線上に設置される。また、複数の計算機111、112、113、は、LAN110を介して通信装置101に接続される。複数の計算機121、122、123は、LAN120を介して、通信装置102に接続される。
 また、通信装置101、102とWAN140は、アクセス回線191、192で接続されている。
 通信装置101は、例えば、特許文献2で開示されるような独自TCPによる送信帯域制御を実行するモードを選択し、選択されたモードに従って帯域制御を行う送信帯域制御部150を有する。通信装置102は、通信装置101とのWAN140を介して通信を高速化するために必要なACK送信部155を備える。図1に示す通信装置101、及び通信装置102では、計算機間でのデータ通信を行うための2種類のコネクションを確立される例を示す。第一のコネクションは、送信帯域制御部150による帯域制御を行う、計算機111及び121間のコネクション160(独自TCP)である。第2のコネクションは、送信帯域制御部を介さない、計算機113及び123間の通常TCPのコネクション163である。なお、送信帯域制御部150及びACK送信部155双方が通信装置101や102に備えられていてもよい。
 ルータ185は、LAN(図示せず)を介して計算機134に接続される。ルータ185は、WAN140を介してルータ186や、通信装置102に接続される。ルータ186は、LAN130を介して複数の計算機131、132、133と接続される。図1に示す計算機131からのコネクション165は、通常TCPのコネクションで、WANを介してルータ185は、計算機134と計算機131とのTCPプロトコルに従ったデータ通信を行う。
 図1のように独自TCPによるコネクション160、通常TCPによるコネクション163及び165の通信では、回線192を共有する場合が生じる。独自TCPによるコネクションで、通信装置101が、送信帯域を急激に増加させる制御をすると、回線帯域を占有してしまい、通常のTCPコネクションを用いた通信が十分な通信帯域を確保できないケースがある。また、通信装置101においても、独自TCPのコネクション160と通常TCPのコネクション163は、回線192だけではなく、回線191も共有する。コネクション160と163間でも同様に、通常のTCPであるコネクション163を用いた通信が十分な通信帯域を確保できない。そのため、以下、通信装置101や102で、他のコネクションの帯域が確保できるよう、独自TCPによるコネクションにおける送信帯域の制御に関する例を詳細に説明する。
 なお、計算機、通信装置及びネットワークの数は図示以外にも適宜の数を備えても良い。計算機は、サーバーや情報処理装置、端末、携帯型情報処理端末、スマートフォン等を含む。計算機間の通信は、クライアントサーバ間のデータ転送や、情報処理装置間のファイル転送等を含む。また、計算機間の通信は、Transmission Control Protocol(トランスミッション コントロール プロトコル、TCP)は、OSI参照モデルのトランスポート層にあたる伝送制御プロトコルに基づく通信を例として以下説明する。また、WAN140は、LANに比べると長い拠点間を結ぶネットワークや、拠点間での通信の遅延が大きいネットワークを含む。
 図2には、本実施の形態の通信装置200のブロック図を示す。図1の通信装置101、102に相当する。
 通信装置200は、例えば、外部のWAN/LANネットワークとのパケットの送受信を行うWAN側及びLAN側のネットワークインターフェース(201/211)と、高速化非対象のTCPパケットやTCP以外のUDPパケットやARPパケット等を素通しさせるためのフィルタ(202/210)と、TCP通信のための制御を行うWAN側及びLAN側のTCP処理部203/209と、WAN側のTCP209の管理するN個の送信バッファ207およびN個の受信バッファ208と、LAN側のTCP203の管理するN個の送信バッファ205およびN個の受信バッファ204と、送受信バッファ間でデータの乗せ換えを行うプロキシ206と、を備える。通信装置200は、メモリ(図示せず)を備え、メモリには、N個のエントリを備えた状態テーブル(状態記憶領域)212と、N個のエントリを備えた帯域テーブル213と、各TCP通信の通信モードや最低帯域を指定するモード/最低帯域指定テーブル740とを保持する。なお、上述のN個は、それぞれ異なる数でもよい。
 フィルタ202/210は、外部から入力されるパケットが、独自TCP対象パケット化否かを、判別し、高速化非対象のTCPパケットやTCP以外のUDPパケット(IPプロトコル番号)やARPパケット等を素通しさせる。TCPパケットの場合、TCPパケットが、IPアドレスとポート番号の組み合わせあるいはいずれか一方を用いて非対象パケットかどうかが判別される。図1のコネクション163でのパケットがその例である。一方、入力パケットが、TCP以外のUDPパケットに該当するかは、IPプロトコル番号で判別される。入力パケットが、ARPパケットであるかは、イーサータイプがIPv4,v6いずれにも該当せず、イーサタイプがARPであるかどうかで判別される。フィルタで該当したパケットは、独自TCPの処理はされず、LAN側からの入力パケットは、WANに転送され、WAN側からの入力パケットは、LANに転送される。
 TCP処理部203、209、プロキシ206については、後に詳述しここでは概略を述べる。
 LAN側のTCP処理部203は、送信履歴更新部725と、パケット再送部724と、受信履歴更新部726と、振分部728と、集約部732とを備える。受信履歴更新部726は、受信したパケットデータを、LAN側受信バッファ204に蓄積する。更に、受信履歴更新部726は、蓄積したデータに応じて、状態テーブル212のバッファ管理ポインタ(508~510、515~517、521~527)の情報を更新する。更に、受信履歴更新部726は、受信したデータの位置を記載したACKパケットを集約部732経由で返信する。送信履歴更新部725は、LAN側送信バッファ205から読み出した送信データをパケットにして送信すると共に、読み出したデータに応じて、状態テーブル212のバッファ管理ポインタ(508~510、515~517、521~527)の情報を更新する。詳細は、図7Bにて説明する。
 WAN側のTCP処理部209は、送信帯域制御部715と、送信履歴更新部705と、パケット再送部704と、受信履歴更新部706と、振分部708と、集約部712とを備える。受信履歴更新部706は、受信したパケットデータを、WAN側受信バッファ208に蓄積する。更に、受信履歴更新部706は、蓄積したデータに応じて、状態テーブル212のバッファ管理ポインタ(508~510、515~517、521~527)の情報を更新する。更に、受信履歴更新部706は、受信したデータの位置を記載したACKパケットを集約部712経由で、WAN140を介して、他の通信装置200に送信する。詳細は、図7Aにて説明する。
 送信帯域制御部715は、送信帯域と再送帯域とACK受信数(WAN140を介して受信されるACKの数)の情報を帯域テーブル213に蓄積する。送信履歴更新部705は、WAN側送信バッファ207から読み出した送信データをパケットにして送信すると共に、読み出した送信データサイズに応じて、状態テーブル212のバッファ管理ポインタ(508~510、515~517、521~527)の情報を更新する。
 プロキシ206は、データ読出し部(601、606)と、データ加工部(602、605)と、データ書込部(603、604)を備える。データ読出部(601、606)は、受信バッファ(204、208)から読み出したデータサイズに応じて、状態テーブル212のバッファ管理ポインタ(508~510、515~517、521~527)の情報を更新する。データ書込部(603、604)は、送信バッファ(207、205)に書き込んだデータサイズに応じて、状態テーブル212のバッファ管理ポインタ(508~510、515~517、521~527)の情報を更新する。詳細は図6にて説明する。
 図3には、送受信バッファ管理用のポインタの説明図を表す。本図では、データを左から右に書き込んでいき、左から右に読み出していくものとする。
 受信バッファは、受信したデータの末尾を示すポインタright_recv303と、整列済みデータと未整列データの境界を示すポインタleft_recv302と、プロキシ206がすでに読出し済のデータとまだ読出していないデータの境界を示すleft_rbuf301と、を管理する。
 受信したデータの末尾を示すポインタright_recv303は、ロスの発生が無く、前から順番にデータを受信すると、受信したデータサイズ分増えて、右へ移動する。受信できずに歯抜けになっているデータ箇所(ロスセグメント)が存在する状態で、再送パケットを受信して、ロスセグメントが消滅すると、整列済みデータと未整列データの境界を示すポインタleft_recv302は、最も小さなロスセグメントの左端まで移動する。プロキシ206は、読出済データと未読出データの境界を示すleft_rbuf301から右へ向かって順番にデータを読み出し、読み出したデータサイズ分、left_rbuf301を右へ移動させる。読み出せるデータサイズの最大値は、left_recv302とleft_rbuf301の差である。
 送信バッファは、プロキシ206が書込済みで送信可能な状態となっているデータの末尾を表すポインタright_sbuf306と、すでに送信済みのデータの末尾を示すポインタright_send305と、受信側から確認応答を受信済みのデータの末尾を示すポインタleft_send304と、を管理する。
 プロキシ206が書込済みで送信可能な状態となっているデータの末尾を表すポインタright_sbuf306は、プロキシ206がデータを書き込む毎に、書き込んだデータサイズ分増加し、右へ移動する。送信済みデータの末尾を示すポインタright_send305を始点として右に向かって新たなデータが送信され、right_send305は、送信されたデータサイズ分増加し、右へ移動する。受信側から、left_send304よりも大きな受信シーケンス番号を持つ確認応答パケットを受信すると、left_send304は、確認応答(ACK)パケットに記載された受信シーケンス番号へと増加し、右へ移動する。
 図4には、通信装置が送受信するパケットのフォーマット図を表す。パケットは、MACヘッダ400、IPヘッダ410、TCPヘッダ420、TCPオプションヘッダ430、ペイロード450を含む。MACヘッダ400は、宛先MACアドレスを表すDMAC401と、送信元MACアドレスを表すSMAC402と、MACフレームタイプを表すType403を含む。IPヘッダ410は、MACヘッダを除くパケット長を表すIP length411と、プロトコル番号を表すprotocol412と、送信元IPアドレスを表すSIP413と、宛先IPアドレスを現すDIP414とを含む。TCPヘッダ420は、送信元ポート番号を表すsrc.port421と、宛先ポート番号を表すdst.port422と、送信シーケンス番号を表すSEQ423と、受信シーケンス番号を表すACK424と、TCPフラグ番号を表すflag425と、TCPのヘッダ長を表すtcp hlen426とを含む。TCPオプションヘッダ430は、オプション種別を表すoption kind431と、オプション長を表すoption length432と、どこからどこまで部分的に受信できたかデータ箇所の位置を送信計算機に通知するために用いられるleft_edge_1~4(433、435、437、439)、right_edge_1~4(434、436、438、440)を含む。left_edge_1~4(433、435、437、439)、right_edge_1~4(434、436、438、440)は、部分的に受信できなかったデータ箇所の位置を通知するために用いられるケースもある。更に、TCPオプションヘッダ430は、TCP通信を開始するときに、装置間の情報交換などに使用するケースもある。
 例えば、MSSオプションは、TCP通信を開始するときに、自装置の受信可能なMSSのサイズを対向装置に通知するために用いられる。SACKオプションは、図1の通信装置101及び102の間で、TCP通信を開始するときに、自装置がSACKオプションに対応可能であることを対向装置に通知するために用いられるだけでなく、通信中に廃棄が検出されたときに部分的に受信出来た箇所を対向装置に通知するためにも用いられる。タイムスタンプオプションは、通信中の自装置の受信時刻を対向装置に通知するために用いられる。このように、TCPオプションは、通信開始時および通信中に、自装置の対応可能な機能や情報を対向装置に伝えるために用いられる。
 図5には、状態テーブル212のフォーマット図を示す。
 通信装置200の状態テーブル212は、例えばTCPコネクション毎の状態を記録するためのn個のエントリ520を有する。
 各エントリ520は、例えば、エントリが使用中であるか否かを記載するVLD501と、LANまたはWAN側のコネクションが確立中であるか否かを記載するconnect_state502と、LAN側の計算機のIPアドレスを表すLIP503と、WAN側の計算機のIPアドレスを表すWIP504と、LAN側の計算機のTCPポート番号を表すLport505と、WAN側の計算機のTCPポート番号を表すWport506と、LAN側のTCP通信の状態を表すlan_state507と、LAN側の受信バッファ管理用のポインタを表すlan_left_rbuf508、lan_left_recv509、lan_right_recv510と、LAN側のウィンドウスケールオプションの値を表すlan_ws511と、LAN側の平均RTTを表すlan_rtt512と、LAN側の輻輳ウィンドウサイズを表すcwnd513と、LAN側の受信バッファから読み出され加工中のデータサイズを表すlan_wan529と、LAN側の送信バッファ管理用のポインタを表すlan_left_send521、lan_right_send522、lan_right_sbuf523と、WAN側のTCP通信の状態を表すwan_state514と、WAN側の受信バッファ管理用のポインタを表すwan_left_rbuf515、wan_left_recv516、wan_right_recv517と、WAN側のウィンドウスケールオプションの値を表すwan_ws518と、WAN側の平均/初期RTTを表すwan_rtt519と、WAN側の最大セグメントサイズMSSを表すwan_mss536と、WAN側の受信バッファから読み出され加工中のデータサイズを表すwan_lan530と、WAN側の送信バッファ管理用のポインタを表すwan_left_send524、wan_right_send525、wan_right_sbuf526と、RTT前のACK受信済み箇所を表すold_wan_left_send527と、通常のTCPに対してフレンドリなモードで通信するか否かを決定するためのfriendly_mode532と、対向装置が独自TCPによる通信に対応していないときに独自TCPによる通信を行うか否かを決定するためのone-way_mode533と、最小帯域を表すmin_token534と、輻輳が検出されない状態になった直近の制御帯域を表すt_token535と、直近の定期更新時の制御帯域を表すc_token537と、帯域が増加し始めた時刻を表すinc_time538とを有する。
 図6には、プロキシ206のブロック図を示す。
 プロキシ206は、LAN側の受信バッファrbuf204からデータを読出すデータ読出し部601と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部602と、加工済みデータをWAN側の送信バッファsbuf207へ書き込むデータ書き込み部603と、WAN側の受信バッファrbuf208からデータを読み出すデータ読出し部606と、読み出したデータに対して圧縮・解凍・暗号化・復号・削除・複製・追記などの加工を行うデータ加工部605と、加工済みデータをLAN側の送信バッファsbuf205へ書き込むデータ書き込み部604とを有する。データ加工部602とデータ加工部605との間で、データのやり取りをしてもよい。データの加工は上述の例以外でもよい。
 データ読出し部601は、lan_left_rbuf508からlan_left_recv509までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。TLS/SSLヘッダに記載された値からは、復号後のチェックサムやヘッダを除いた平文データサイズを推定することができる。SMBヘッダからは、プリフェッチ等を行った後のコマンドデータサイズを推定することができる。推定した加工後のデータサイズが、wan_right_sbuf526とwan_left_send524の差、すなわち未送信データとACK確認待ちデータの合計値が、WAN側の送信バッファサイズwan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部602へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル212のlan_wan528へ記載する。
 データ読出し部606は、wan_left_rbuf515からwan_left_recv516までの間に蓄積されている整列済みデータから読み出した先頭データから、読み出すべきデータサイズと、データ加工後のデータサイズを推定する。先頭データとしては、TLS(Transport Layer Security)/SSL(Secure Socket Layer)ヘッダ、SMB(Server Message Block)ヘッダ、等などを使用してもよい。推定した加工後のデータサイズが、lan_right_sbuf523とlan_left_send521の差、すなわち未送信データとACK確認待ちデータの合計値が、LAN側の送信バッファサイズlan_sbuf_sizeを超えない場合は、データを読み出して、データ加工部605へ転送する。更に、推定した読み出すべきデータサイズと、データ加工後のデータサイズのうち、大きい方を状態テーブル212のwan_lan529へ記載する。
 図7Aには、図2の通信装置200のWAN側のTCP処理部209のブロック図を示す。
 TCP通信を実現するTCP処理部209は、受信処理を行うRX部(受信部)702と、送信処理を行うTX部(送信部)701を有する。
 RX部702は、受信パケットを、SYN,FINなどのフラグが付いたTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部708と、TCP制御パケットに記載されているフラグ番号に基づいて状態テーブル212内のTCP状態(lan_state507、wan_state514)を変更すると共に、TCP制御パケットに記載されているオプション番号の有無や、モード/最低帯域指定テーブル740の指定するモードと最低帯域に基づいて、状態テーブル212内の通信モード(friendly_mode532、one-way_mode533)や最低帯域min_token534を変更するTCP制御部707と、受信したデータパケットの送信シーケンス番号SEQ423と受信シーケンス番号ACK424とに基づいて、状態テーブル212内のバッファ管理ポインタを変更してACKパケットを返信する受信履歴更新部706を有する。
 TCP制御部707が、TCP制御パケットに記載されているオプション番号の有無に基づいて、通信開始時に、通信モード(friendly_mode532、one-way_mode533)を変更する方法は、図18を用いて後述する。
 TCP制御部707が、モード/最低帯域指定テーブル740の指定するモードと最低帯域に基づいて、通信開始時に、通信モード(friendly_mode532)や最低帯域min_token534を変更する方法は、図20を用いて後述する。
 TX部701は、状態テーブル212内のTCP状態lan_state507、wan_state514を用いてTCP制御パケットを送信するTCP制御部703と、受信したACKパケットに基づいて状態テーブル212内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1~4(433、435、436、439)、right_edge_1~4(434、436、438、440)を用いて送信バッファsbuf207からデータを読み出してパケットを再送すると共に、再送ビット長とACK受信数を送信帯域制御部715に通知するパケット再送部704と、送信バッファsbuf207から読み出したデータを載せたパケットを送信して、状態テーブル212内のバッファ管理ポインタを変更すると共に、送信ビット長を送信帯域制御部715に通知する送信履歴更新部705と、再送パケットとデータパケットを受け取り、バッファ1~n(709-1~n)に振り分ける振分部708と、現在時刻を生成して送信帯域制御部715に通知するタイマ713と、インターバル時間(予め定めた固定値、または計測した平均RTTなど)を保存して送信帯域制御部715に通知するインターバル格納部714と、帯域テーブル213を制御して、各TCPコネクションのトークンサイズをトークン更新部717に通知する送信帯域制御部715と、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ712に通知するトークン更新部717と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ712およびバッファ709~711とを有する。モード/最低帯域指定テーブル740の記載内容は、外部のユーザ端末741から変更可能である。
 本実施例において、TX部701の各ブロックのうち、各TCP通信の制御帯域(最大送信帯域)に従いデータを送信するブロック(例えば、トークン更新部717、マルチプレクサ712、バッファ709等)をまとめて送信制御部と称することもある。
 図7Bには、図2におけるLAN側のTCP処理部203のブロック図を示す。
 TCP通信を実現するTCP処理部203は、受信処理を行うRX部(受信部)722と、送信処理を行うTX部(送信部)721を有する。
 RX部722は、受信パケットをTCP制御パケットとデータ付パケットとACKパケットに分離するパケット振分部728と、受信したTCP制御パケットに基づいて状態テーブル212内のTCP状態lan_state507、wan_state514を変更するTCP制御部727と、受信したデータパケットの送信シーケンス番号SEQ423と受信シーケンス番号ACK424とに基づいて、状態テーブル212内のバッファ管理ポインタを変更してACKパケットを返信する受信履歴更新部726とを有する。
 TX部721は、状態テーブル212内のTCP状態lan_state507、wan_state514を用いてTCP制御パケットを送信するTCP制御部723と、受信したACKパケットに基づいて状態テーブル212内のバッファ管理ポインタを変更し、受信したACKパケット記載の部分的確認応答left_edge_1~4(433、435、436、439)、right_edge_1~4(434、436、438、440)を用いて送信バッファsbuf205からデータを読み出してパケットを再送するパケット再送部724と、送信バッファsbuf205から読み出したデータを載せたパケットを送信して、状態テーブル212内のバッファ管理ポインタを変更する送信履歴更新部725と、ACKパケット、TCP制御パケット、再送パケット、データパケットをFIFOで集約して、出力するマルチプレクサ732およびバッファ729~731とを有する。
 WAN側TCP処理部209の送信帯域制御部715、帯域テーブル213内に基準時刻という内部変数を管理している。基準時刻と、タイマ713の現在時刻との差が、インターバル格納部714のインターバル時間よりも大きくなると、基準時刻にインターバル時間を加算して新たな基準時刻とする。加算前の基準時刻は、旧基準時刻となる。すなわち、現在使用している基準時刻の一つ前に使用していた基準時刻は旧基準時刻となる。インターバル時間には、計測した平均RTTや初期RTT(wan_rtt519)を用いることもあれば、固定値を用いることもある。
 図2を用いて、LAN側からデータ付きパケットを受信した際の、通信装置200におけるパケットの流れを説明する。
 LAN側から到着したデータ付きパケットは、LAN側TCP処理部203に入り、受信履歴更新部726に到着する。受信履歴更新部726は、データ付きパケットに対するACKパケットを集約部732経由でLAN側に返信し、パケットに記載されたデータをLAN側受信バッファrbuf204へと蓄積する。更に、受信履歴更新部726は、蓄積データサイズに基づいて状態テーブル212のポインタを更新する。データ読出し部601は、LAN側受信バッファrbuf204に蓄積された整列済みデータを読出し、データ加工部602へ転送する。更に、読み出したデータサイズに基づいて状態テーブル212のポインタを更新する。
 データ加工部602は、データを加工して、データ書き込み部603へ転送する。更に、加工中のデータサイズに基づいて状態テーブル212の加工中データサイズを更新する。データ書き込み部603は、加工済みデータをWAN側送信バッファsbuf207へと書き込む。更に、書き込んだデータサイズに基づいて状態テーブル212のポインタを更新する。WAN側送信バッファsbuf207に書き込まれたデータは、送信履歴更新部705から読み出される。送信帯域制御部715は、読み出されたデータを、WAN側へデータ付きパケットとして送信する制御を行う。
 受信履歴更新部726についてさらに説明すると、LAN側の受信バッファの最大値から、lan_right_recv510とlan_left_rbuf508との差分を、引くことで、受信バッファの残存量を計算する。ペイロード450のサイズが、受信バッファの残存量以下のときは、ペイロード450に記載されたデータ全てを受信バッファに格納する。ペイロード450のサイズが、受信バッファの残存量よりも大きい場合は、ペイロード450の先頭から受信バッファの残存量に相当するサイズのデータだけを受信バッファに格納する。格納データサイズが0よりも大きいときは、データ付きパケットのTCPヘッダ420に記載されたSEQ423の値と、格納データサイズに基づいて、受信バッファ管理用ポインタの更新を行う。例えば、パケットヘッダ記載のSEQ423に格納データサイズを加算した値が、lan_right_recv510よりも大きい場合は、lan_right_recv510を、SEQ423に格納データサイズを加算した値に変更する。更に、受信データの最後尾がlan_right_recv510となるように、受信データをLAN側の受信バッファに記載する。その後、受信バッファ管理ポインタの1つlan_left_recv509をTCPヘッダ420のACK424に記載したACKパケットを、LAN側へ返信する。
 また、送信履歴更新部705についてさらに説明すると、wan_right_send525から右方向に、最大wan_right_sbuf526までのデータを、WAN側送信バッファsbuf207から読み出す。wan_right_send525は、読み出したデータサイズ分、増加して、右に移動する。更に、読み出したデータをペイロード450に記載し、wan_right_send525をSEQ423に記載したTCPヘッダ420を追加したデータ付きパケットを、WAN側へ送信する。
(WAN側に出て行くデータの送信帯域の制御に使用する変数)
 送信帯域制御部715は、帯域テーブル213が管理する変数を用いて、各TCP通信のWAN側に出て行くデータの送信帯域を制御する。
 図8には、送信帯域制御部715が管理する帯域テーブル213のフォーマットを表す。
 帯域テーブル213は、コネクション毎に、基準時刻と、基準時刻後の送信ビット積算値・再送ビット積算値・ACK受信数・制御帯域と、基準時刻前の送信帯域・再送帯域・受信帯域・制御帯域と、旧基準時刻前の送信帯域・制御帯域と、を記録する。
 基準時刻後の制御帯域は、現在時刻における制御帯域を表す(本実施例では、tokenまたはトークンと表す)。基準時刻後の送信帯域は、現在時刻における送信帯域を表し(本実施例では、sndと表す)、基準時刻後の送信ビット積算値を、現在時刻と基準時刻の差分で除算することで求められる。基準時刻後の再送帯域は、現在時刻における再送帯域を表し(本実施例では、rtsと表す)、基準時刻後の再送ビット積算値を、現在時刻と基準時刻の差分で除算することで求められる。基準時刻後の受信帯域は、現在時刻における受信帯域を表し(本実施例では、rcvと表す)、基準時刻後のACK受信数にWAN側のMSSと8を積算した値を、現在時刻と基準時刻の差分で除算することで求められる。基準時刻前の制御帯域・送信帯域・受信帯域・再送帯域は、旧基準時刻から基準時刻までの制御帯域・送信帯域・受信帯域・再送帯域の平均値を表す(本実施例では、old_token、old_snd、old_rcv、old_rtsと表す)。旧基準時刻前の制御帯域・送信帯域は、旧基準時刻の直前までの制御帯域・送信帯域を表す(本実施例では、old_old_token、old_old_snd、と表す)。基準時刻前の再送率/廃棄率old_rts_ratioは、old_rts/old_old_snd、または、1-old_rcv/old_old_sndで求められる。また、基準時刻後の現在の再送率/廃棄率rts_ratioは、rts/old_snd、または、1-rcv/old_sndで求められる。インターバル時間として、固定値を用いることもあれば、状態テーブル212記載のwan_rtt519を用いる場合もある。
 図11には、旧基準時刻・基準時刻・現在時刻と、その前後の制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の関係を表す。
 基準時刻と旧基準時刻との差は、インターバル時間である。旧基準時刻前におけるインターバル時間の制御帯域・送信帯域の平均値は、old_old_token、old_old_sndと表す(1103)。旧基準時刻から基準時刻までの間の制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、old_token、old_snd、old_rcv、old_rts、old_rts_ratioと表す(1102)。基準時刻から現在時刻までの制御帯域・送信帯域・受信帯域・再送帯域・再送率/廃棄率の平均値は、token、snd、rcv、rts、rts_ratioと表す(1101)。
 送信帯域制御部715は、帯域テーブル213に記載された上述の値を用いて、廃棄率/再送率(rts_ratio530とold_rts_ratio531)を計算する。現在時刻の廃棄率/再送率rts_ratio530は、rts/old_tokenまたはrts/old_sndまたは1-rcv/old_tokenまたは1-rcv/old_sndで計算される。過去の廃棄率/再送率old_rts_ratio531は、old_rts/old_old_tokenまたはold_rts/old_old_sndまたはまたは1-old_rcv/old_old_tokenまたは1-old_rcv/old_old_sndで計算される。更に、廃棄率/再送率の変化(old_rts_ratio531とrts_ratio530の比率)に基づいて、制御帯域(tokenまたはトークン)を決定し、トークン更新部717へ伝える。更に、状態テーブル212を更新する。制御帯域(tokenまたはトークン)の更新方法の詳細は、図12~図16に後述する。
 トークン更新部717は、送信帯域制御部715から伝えられた制御帯域(tokenまたはトークン)の値に基づいて、TCPコネクション毎にトークンバケツを管理して、送信可能なコネクションをマルチプレクサ712に通知する。
(制御帯域tokenの更新処理)
 図9と図10と図17の説明図と、図12~図16のフローチャートを用いて、送信帯域制御部715が制御帯域(tokenまたはトークン)を更新する方法の詳細を説明する。
 図9には、通常のTCP通信と独自TCPによる通信との差異、および、独自TCPの送信帯域の制御方法の説明図を示す。
 通常のTCP通信では、廃棄が1回でも生じると、輻輳を検出したと判定して、送信帯域を一定の割合で減少させる(906)。ネットワークでは、ボトルネックの帯域が100%使われていなくても、待ち行列理論に基づく確率的な廃棄が一定の割合で発生する。そのため、送信帯域がボトルネック帯域に到達してトップスピードになる前に減少してしまい、ボトルネックの帯域を100%使い切ることができなかった。
 独自TCPでは、直近の再送帯域をRTT前の送信帯域で除算することで廃棄率を求め、廃棄率の変化率が予め定めた閾値kを超過したときに、輻輳が発生したと判断して、RTT前の送信帯域と直近の再送帯域に基づいて、送信帯域を減少させる(902)。送信帯域がボトルネック帯域へ到達したことを、廃棄率の変化率の増加により判断する。これにより、確率的な廃棄の影響を受けずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となる。
 独自TCPでは、送信帯域を減少させた後(902)、ACK受信済み箇所の位置が変わるまで、ACK受信数に応じて送信帯域を一定にする(903)。ACK受信済み箇所の位置が更新され始めると、一定時間Tの間は緩やかに、例えば線形的に、送信帯域を増加させる(904)。緩やかに、例えば線形的に、送信帯域を増加させ続けて一定時間Tが経過すると、急激な増加方法(例えば、指数的などの非線形的な増加方法)に変更する(905)。期間Tは、RTTとトークン(token:制御帯域)によって定めても良いし、これらの積に比例させてもよい。これにより、送信帯域を線形的に増加させる期間が、RTTと送信帯域の過去の履歴によって決定する通信装置が実現される。つまり、送信帯域制御部715は、第一の制御モードと第二の制御モードを備え、第一の制御モードで帯域制御が所定の期間経過後、第2の制御モードでの帯域制御に切り替える制御を行う。第2の制御モードでの送信帯域の増加率は、第一の制御モードでの増加率よりも高くてもよい。なお、一定の期間Tは、通信装置200に接続される管理端末等により変更可能な所定の期間である。
 上述の送信帯域の制御方法により、ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させ、その後、送信帯域を非線形的に増加させる通信装置が実現される。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出する通信装置と、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、廃棄率または再送率とそれらの変化率を推定する通信装置と、輻輳を検出したときに、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、送信帯域を減少させる通信装置が実現される。
 ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、送信帯域を通常のTCP通信よりも緩やかに(例えば線形的に)増加させることで、通常のTCP通信と競合したときでも、通常のTCP通信の帯域を圧迫することを防ぎ、通常のTCP通信が帯域を確保しやすくなる。また、一定時間が経過した後に、急激に(例えば指数的に)送信帯域を増加させることで、通常のTCP通信との競合が無い時に、送信帯域がボトルネック帯域へ到達してトップスピードになる時間を短くすることが出来る。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、確率論的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となる。
 図10には、独自TCPによる通信を行っている装置の送信側の送信帯域1001、廃棄率1002、廃棄率の変化率1003の時間遷移を示したグラフを示す。
 独自TCPによる通信の送信帯域の増減には、大きく4つのフェーズが存在する。フェーズ1は送信帯域を増加させるステップ、フェーズ2は送信帯域を減少させるステップ、フェーズ3は送信帯域を過去の送信帯域へ戻すステップ、フェーズ4は送信帯域を一定にするステップ、となる。
 まず、フェーズ1で送信帯域が増加していき(1004)、ある時にボトルネック帯域を超過する(1013)。送信帯域がボトルネック帯域を超過すると、パケット廃棄が発生するが、廃棄箇所が受信側から送信側に通知されるまでにRTT以上かかる。そのため、送信帯域がボトルネック帯域を超過したことが、廃棄率の増加となって現れるのは、RTT以上後となる(1014)。廃棄率は、直近の再送帯域をRTT前の送信帯域で除算することで求められる。送信帯域がボトルネック帯域よりも小さい間は、確率的な廃棄しかおきないため、廃棄率は一定となる(1010)。送信帯域がボトルネック帯域を超過してからRTT以上経過すると、確率的な廃棄に加えて、使い過ぎによる廃棄(1011)が加わるようになるため、廃棄率が増加しはじめる(1012)。廃棄率が増加しはじめると、廃棄率の変化率は1から急激に増加し、閾値kを超過する(1009)。
 独自TCPによる通信では、上記のように、廃棄率の変化率が急激に増加し、閾値kを超過したときに、ネットワークに輻輳が発生したと判断する。
 ネットワークに輻輳が発生したと判断すると、RTT前の送信帯域から、現在の再送帯域を引いた値を、新たな送信帯域とする(1018)。RTT前の送信帯域を用いて新たな送信帯域を計算する理由は、送信帯域がボトルネック帯域を超過した時間がRTT以上前だからである。廃棄率の増加はしばらく継続するため(1012)、その間は送信帯域が減少し続ける。この送信帯域を減少させるステップがフェーズ2となる(1005)。
 送信帯域が減少していきボトルネック帯域よりも小さくなると、廃棄率が減少しはじめる(1019)。廃棄率の変化率が1よりも小さくなり、閾値kを下回ると(1020)、ネットワークに輻輳が発生しなくなったと判断される。
 ネットワークに輻輳が発生しなくなったと判断された後も、廃棄パケットの再送処理は継続している。受信確認済みのデータ箇所がRTT前と比較して増加していない場合は、廃棄パケットの再送処理は継続していると判断して、ACK受信数に応じて、送信帯域を一定とする。この送信帯域を一定とするステップがフェーズ4となる(1006)。
 受信確認済みのデータ箇所がRTT前と比較して増加している場合は、廃棄パケットの再送処理が一通り完了したと判断して、再び送信帯域を増加させる(フェーズ1)。
 最初は、送信帯域制御部715は、送信帯域をゆっくりと、例えば、第一の制御モードで、線形的に増加させていく(1007)。一定の期間T、輻輳が検出されないと、その後、送信帯域制御部715は、第二の制御モードで送信帯域を急激に(例えば、非線形的に)増加させていく(1008)。非線形的に増加させるときは、RTT毎にα倍するなど、指数的に増加させてもよい(1016)。最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく期間Tは、RTTとトークン(token:制御帯域)によって定めても良いし、これらの積に比例させてもよい(1021)。また、最初の送信帯域をゆっくりと(例えば、線形的に)増加させていく間は、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させてもよいし、送信帯域をRTT毎にMSS/RTTに比例する速度で線形的に増加させる場合の比例係数αを1よりも小さい値にしてもよい(1017)。これにより、送信帯域を線形的に増加させる期間が、RTTと送信帯域の過去の履歴によって定まる通信装置が実現される。
 上述の送信帯域の制御方法により、ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させ、その後、送信帯域を非線形的に増加させる通信装置が実現される。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出する通信装置と、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、廃棄率または再送率とそれらの変化率を推定する通信装置と、輻輳を検出したときに、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、送信帯域を減少させる通信装置が実現される。
 ネットワークの輻輳が検出されず、尚且つ、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、送信帯域を通常のTCP通信よりも緩やかに(例えば線形的に)増加させることで、通常のTCP通信と競合したときでも、通常のTCP通信の帯域を圧迫することを防ぎ、通常のTCP通信が帯域を確保しやすくなる。また、一定時間が経過した後に、急激に(例えば指数的に)送信帯域を増加させることで、通常のTCP通信との競合が無い時に、送信帯域がボトルネック帯域へ到達してトップスピードになる時間を短くすることが出来る。更に、廃棄率や再送率の変化率を用いて、ネットワークの輻輳を検出することで、確率的な廃棄に影響されずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させ続けることが可能となり、回線帯域を使い切ることが出来るようになる。
 図12~図16には、送信帯域制御部715が制御帯域(tokenまたはトークン)を更新する方法の詳細を説明するためのフローチャートを示す。
 図12~図15には、独自TCPにおける帯域制御の詳細を、図16には、独自TCPによる通信が回線帯域を占有せずに、通常のTCPによる通信を保護するための帯域増加方法の詳細を示す。
 図12Aには、送信帯域制御部715が制御帯域(tokenまたはトークン)を更新する際の概念的なフローチャートを表す。独自TCPでは、送信帯域制御部715が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。図12Aの各ステップは、送信帯域制御部715により実行される。
 送信帯域制御部715において、制御帯域の更新処理がスタートすると(ステップ1201)、送信帯域制御部715は、パケット再送率(=rts/old_tokenまたはrts/old_sndまたは1-rcv/old_tokenまたは1-rcv/old_sndで計算される値)の増加率が、予め定められた閾値を超過したか否かを判定する(ステップ1202)。パケット再送率の増加率が、予め定められた閾値を超過した場合は、現在の再送帯域(rts)と、過去の(基準時刻より前の)制御帯域(old_token)または過去の(基準時刻より前の)送信帯域(old_snd)を用いて、制御帯域(token)を更新する(ステップ1203)。例えば、過去の(基準時刻より前の)制御帯域を、現在の再送帯域に応じた量減らし、現時刻の制御帯域とする。一方、ステップ1202において、パケット再送率の増加率が、予め定められた閾値を超過しなかった場合は、送信帯域制御部715は、制御帯域を増加させる(ステップ1204)。ステップ1203やステップ1204のあとに、送信帯域制御部715は、各コネクションの最小帯域(min_token534)に基づき、制御帯域(token)を更新する(ステップ1206)。制御帯域(token)を変更することで、トークンバケツに蓄積されるトークンの量が変わり、それによりパケットの送信レートを変更することが可能となる。
 図12Bには、送信帯域制御部715が帯域テーブル213記載の値を用いて、制御帯域(token)を変更するフローチャート図を表す。図12Aをより詳細にした例を示す。図12Bの各ステップは、送信帯域制御部715により実行される。独自TCPでは、送信帯域制御部715が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。
 制御帯域(token)の更新処理がスタートすると(ステップ1207)、送信帯域制御部715が、タイマ713の出力する現在時刻と、帯域テーブル213記載の基準時刻との差が、インターバル格納部714の出力するインターバル時間以上であるか否かを判定する(ステップ1208)。インターバル時間として、計測したRTTの平均値や初期値等を記録した状態テーブル212のwan_rtt519等を使用してもよい。ステップ1208において真と判断された場合は、基準時刻後の現在の制御帯域tokenの値をtmpに退避させておく(ステップ1209)。更に、例えば、帯域テーブル213に記憶された再送ビット積算値(基準時刻後)/(現在時刻-基準時刻)/送信帯域(基準時刻前)で求められる再送率(基準時刻後)rts_ratioが、再送帯域(基準時刻前)/送信帯域(旧基準時刻前)で求められる旧再送率(基準時刻前)old_rts_ratioのK倍(K:予め定められた1以上の係数)よりも大きいか否かを判定する(ステップ1210)。ステップ1210は、上述のステップ1202に相当する。Kの値は、固定としてもよいし、tokenの値に応じて変化してもよい。ステップ1210において、大きいと判定した場合は、ネットワークに輻輳が発生していると判断して、制御帯域(基準時刻後)tokenの値を、制御帯域(基準時刻前)old_tokenの値よりも小さくなるように、例えば、再送帯域rtsを用いて減少させる。例えば、制御帯域(基準時刻後)token=制御帯域(基準時刻前)old_token-再送帯域(基準時刻後)rtsなどとする(ステップ1212)。ステップ1212は、上述のステップ1203に相当する。ステップ1210で偽と判定された場合は、制御帯域(基準時刻後)tokenを増加させる(ステップ1211)。制御帯域(基準時刻後)tokenの増加方法は、線形に増加させてもよいし、指数的に増加させてもよいし、線形増加と指数増加を組み合わせても良いし、最初線形増加させてその後で指数増加してもよいし、増加率を制御帯域(基準時刻後)tokenに応じて変化させてもよい。ステップ1211は、上述の1204に相当する。
 ステップ1212またはステップ1211が完了すると、例えば送信帯域(旧基準時刻前)old_old_snd=送信帯域(基準時刻前)old_snd、送信帯域(基準時刻前)old_snd=送信帯域(基準時刻後)snd、再送帯域(基準時刻前)old_rts=再送帯域(基準時刻後)rts、基準時刻=基準時刻+インターバル、送信ビット積算値(基準時刻後)=0、再送ビット積算値(基準時刻後)=0、制御帯域(旧基準時刻前)old_old_token=制御帯域(基準時刻前)old_token、制御帯域(基準時刻前)old_token=tmp、定期更新時の制御帯域c_token=新たな制御帯域token、などと更新し、各値を帯域テーブル213や状態テーブル212に記録する(ステップ1213)。その後ステップ1217に移る。
 一方、ステップ1208で、偽と判定された場合は、ステップ1210と同様に、再送ビット積算値(基準時刻後)/(現在時刻-基準時刻)/送信帯域(基準時刻前)で求められる再送率(基準時刻後)rts_ratioが、再送帯域(基準時刻前)/送信帯域(旧基準時刻前)で求められる旧再送率(基準時刻前)old_rts_ratioのK倍(K:予め定められた1以上の係数)よりも大きいか否かを判定する(ステップ1214)。Kの値は、固定としてもよいし、tokenの値に応じて変化してもよい。ステップ1214は、上述のステップ1202に相当する。ステップ1214において大きいと判定した場合は、ネットワークに輻輳が発生していると判断して、ステップ1212と同様に、制御帯域(基準時刻後)tokenの値を、制御帯域(基準時刻前)old_tokenの値よりも小さくなるように、例えば再送帯域rtsを用いて減少させる。例えば、制御帯域(基準時刻後)token=制御帯域(基準時刻前)old_token-再送帯域(基準時刻後)rtsなどとする(ステップ1215)。ステップ1214において小さいあるいは同等と判定した場合は、何もしない。これらのステップにより、インターバル時間が経過しなくても、再送率の増加からネットワークの輻輳を即座に検出し、制御帯域を更新できる。これらのステップの後、ステップ1217に移る。
 ステップ1217では、制御帯域(基準時刻後)tokenが、各TCP通信の最小帯域min_tokenよりも小さい場合は、制御帯域(基準時刻後)tokenを各TCP通信の最小帯域min_token534に変更する(ステップ1217)。すなわち図12Bのステップ1217で示す2つの式で定まるtokenのうちいずれか小さいほうをとる。なお、ステップ1217におけるtokenやmin_token534などのデータは、状態テーブル212や帯域テーブル213を参照して読み出すことができる。制御帯域(token)を変更することで、トークンバケツに蓄積されるトークンの量が変わり、それによりパケットの送信レートを変更することが可能となる。
 上述のように、独自TCPでは、図12を用いて説明したフローチャートのように、廃棄率または再送率に基づく帯域制御を行うことで、確率論的な廃棄の影響を受けずに、送信帯域がボトルネック帯域に到達してトップスピードになるまで、送信帯域を増加させることが出来るようになる。これにより、独自TCPは、RTTと廃棄率に依存せずに、回線帯域を使い切ることが出来る。
 図13、図14、図15には、送信帯域制御部715が帯域テーブル213記載の値を用いて、制御帯域(token)を変更するフローチャート図を表す。図12Bの一部をより詳細にした例を示す。図13がメインのフローチャート、図14と図15は、図13の処理の一部を詳細化したフローチャートである。図13、図14、図15の各ステップは、送信帯域制御部715により実行される。独自TCPでは、送信帯域制御部715が、本フローチャートに従い処理を実行することで、再送率に基づく帯域制御を実現し、RTTと廃棄率に依存せず、回線帯域を使い切ることができる。
 図13には、送信帯域制御部715が帯域テーブル213記載の値を用いて、制御帯域(token)を変更するメインのフローチャート図を表す。
 送信帯域制御部715は、初めに廃棄率の計算を行う(1301)。廃棄率は、前述の図11を用いた説明のように、rts/old_tokenまたはrts/old_sndまたは1-rcv/old_tokenまたは1-rcv/old_sndで計算される。廃棄率として、再送率を用いることもある。次に、tokenの値に応じて、閾値kの調整を行う(1302)。tokenの値が大きいときは、閾値kを小さくすることで、廃棄率が少し増加しただけでも、廃棄率の変化率が閾値kを超えやすくなり、ネットワークの輻輳を検出しやすくする。次に、前回の定期更新からRTTが経過したか否かを判定する(ステップ1303)。これは、現在時刻と基準時刻との差がインターバル以上であるか否かを判定するステップ1208に相当する処理である。RTT経過した場合は、RTT毎に行う定期更新処理を行う(1304)。RTT経過してない場合は、不定期の更新処理を行う(1305)。定期更新1304と不定期更新1305の詳細は、それぞれ図14と図15を用いて後述する。定期更新1304と不定期更新1305の後、アクティブコネクション数とアクセス帯域に基づいて、制御帯域(token)を更新する処理を行う(1306)。この処理により、コネクション間の公平性が確保される。更に、各TCPコネクション通信の最小帯域min_token534に基づいて、制御帯域(token)を更新する(ステップ1307)。
 図14には、送信帯域制御部715が行う、制御帯域(token)の定期更新処理1304の詳細なフローチャート図を示す。
 送信帯域制御部715が行う定期更新処理1304では、初めに廃棄率(rts_ratio)の増加率が閾値kを超過したか否かを判定する(ステップ1401)。廃棄率(rts_ratio)の増加率が閾値kを超過している場合は、送信帯域制御部715は、0~RTT前の再送帯域rtsと、RTT~2RTT前の送信帯域old_sndまたは制御帯域old_tokenに基づき新たな制御帯域を決定する(ステップ1402)。例えば、新たな制御帯域token=制御帯域(基準時刻前:RTT~2RTT前)old_token-再送帯域(基準時刻後:0~RTT前)rtsなどとする(ステップ1402)。本願では、ステップ1402のことをフェーズ2と呼ぶ。次に、現在のACK受信済み箇所wan_left_send524と、RTT前のACK受信済み箇所を表すold_wan_left_send527の値を比較し(ステップ1403)、変化していればRTT毎の定期更新1304を終了する。変化していない場合は、ステップ1405に進む。
 ステップ1401において、廃棄率(rts_ratio)の増加率が閾値kを超過していない場合は、送信帯域制御部715は、現在のACK受信済み箇所wan_left_send524と、RTT前のACK受信済み箇所を表すold_wan_left_send527の値を比較する(ステップ1404)。変化していない場合は、ステップ1405に進む。ステップ1405では、送信帯域制御部715は、WAN側の送信バッファ207を参照し、、未送信データがあるか否かを判断する(ステップ1405)。未送信データが送信バッファ207にある場合は、送信帯域制御部715は、0~RTT前のACK受信数に基づいて、制御帯域を調整する(ステップ1406)。例えば、新たな制御帯域=受信帯域(基準時刻後:0~RTT前)rcvなどとする(ステップ1406)。ステップ1406が終わると、送信帯域制御部715は、RTT毎の定期更新1304を終了する。また、ステップ1404において、現在のACK受信済み箇所wan_left_send524が、RTT前のACK受信済み箇所を表すold_wan_left_send527の値よりも大きくなっている場合は、制御帯域(token)を増加させる(ステップ1407)。本願では、ステップ1407の処理のことをフェーズ1と呼ぶ。ステップ1407が終わると、RTT毎の定期更新1304を終了する。なお、制御帯域(token)を増加させるステップ1407の詳細は、図16を用いて後述する。
 図15には、送信帯域制御部715が行う、制御帯域(token)の不定期更新処理1305の詳細なフローチャート図を示す。
 図13のステップ1303で、現在時刻が、前回のステップ1304のRTT毎の制御帯域更新処理からRTT経過していない場合、送信帯域制御部715が行う不定期更新処理1305では、初めに廃棄率(rts_ratio)の増加率が閾値kを超過したか否かを判定する(ステップ1501)。廃棄率(rts_ratio)の増加率が閾値kを超過している場合は、0~RTT前の再送帯域rtsと、RTT~2RTT前の送信帯域old_sndまたは制御帯域old_tokenに基づき新たな制御帯域を決定する(ステップ1502)。例えば、新たな制御帯域token=制御帯域(基準時刻前:RTT~2RTT前)old_token-再送帯域(基準時刻後:0~RTT前)rtsなどとする(ステップ1502)。本願では、ステップ1502のことを、ステップ1402と同様に、フェーズ2と呼ぶ。ステップ1502が終わると、不定期更新処理1305を終了する。一方、ステップ1501において、廃棄率(rts_ratio)の増加率が閾値kを超過していない場合は、直近の定期更新時の制御帯域(c_token)を使用して、制御帯域(token)を更新する(ステップ1503)。例えば、token=c_tokenなどとする。(ステップ1503)。本願では、ステップ1503のことを、フェーズ3と呼ぶ。
 図13~図15を用いて上述したように、送信帯域制御部715が行う制御帯域(token)の更新処理は、大きく分けて、帯域を増加させるフェーズ1(ステップ1407)と、帯域を減少させるフェーズ2(ステップ1402、ステップ1502)と、帯域を元の値に戻すフェーズ3(ステップ1503)と、帯域をACK受信数に応じて一定にするフェーズ4(ステップ1406)の4種類の処理から構成される。
 図17には、送信帯域制御部715が行う制御帯域(token)の更新処理により、制御帯域(token)が時系列順にどのように変化していくかをグラフにより示す。
 まず初めに、帯域増加のフェーズ1(ステップ1407)があり、次に、帯域を減少させるフェーズ2(ステップ1402、ステップ1502)があり、最後に、帯域をACK受信数に応じて一定にするフェーズ4(ステップ1406)がある。帯域を元の値に戻すフェーズ3(ステップ1503)は、RTT毎の定期更新までの間にある、制御帯域(token)が一定になっているときのフェーズである。
 送信帯域制御部715は、フェーズ2とフェーズ4の時、状態テーブル212の帯域増加開始時刻inc_time538を現在時刻で更新する。更に、フェーズ4の時、状態テーブル212のt_token535を現在の制御帯域(token)で更新する。t_token535は、独自TCPが検出したボトルネック帯域に相当する。
 図16Aには、ステップ1407における帯域増加処理のフローチャート図を示す。
 送信帯域制御部715が行う帯域増加処理1407では、初めに、状態テーブル212に記載されているfriendly_mode532の値をチェックして、通常のTCPに対してフレンドリなモード、つまり第一の制御モードでの通信が有効か否かを判断する。加えて、現在時刻と、帯域増加開始時刻inc_time538との差が、時間Tを超過したか否かを判断する(ステップ1601)。フレンドリモードfriendly_mode532が有効で、尚且つ、現在時刻と帯域増加開始時刻inc_time538との差が、時間Tを超過していない場合は、送信帯域制御部715は、第一の制御モードでゆっくりと帯域を増加させる(ステップ1603)。例えば、新たな制御帯域(token)=元の制御帯域(token)+係数α×最大セグメントサイズMSS×8/RTTなどとする(ステップ1603)。係数αは、例えば1未満にする。フレンドリモードfriendly_mode532が無効、または、現在時刻と帯域増加開始時刻inc_time538との差が、時間Tを超過した場合は、送信帯域制御部715は、第一の制御モードよりも送信帯域の増加率が高い第2の制御モードで、帯域を急激に増加させる(ステップ1602)。例えば、新たな制御帯域(token)=係数α×元の制御帯域(token)などとする(ステップ1602)。
 上述したように、廃棄率の増加率が閾値kを超過しなくなるなど、ネットワークの輻輳が検出されなくなり(ステップ1401)、尚且つ、受信確認済みのデータ箇所が更新中(ステップ1404)の状態が継続するようになってから、一定の期間Tは、送信帯域をゆっくりと、例えば線形的に増加させ(ステップ1603)、その後、送信帯域を急激に、例えば非線形的に増加させる(ステップ1602)ことで、独自TCPを用いた通信が回線帯域を占有することを防ぎ、通常のTCPを用いた通信が通信帯域を確保できるようになる。
 図16Bには、ステップ1407における帯域増加処理の別のフローチャート図を示す。図16Aに分岐処理を一つ加えた例を示す。
 図16Aを用いて説明したステップ1601とステップ1602の間に、新たに分岐処理(ステップ1604)が加わり、ステップ1602とは別の処理(ステップ1605)を実施するフローが加わる。それ以外は、図16Aと同様である。
 ステップ1601において、フレンドリモードfriendly_mode532が有効で、尚且つ、現在時刻と帯域増加開始時刻inc_time538との差が、時間Tを超過していない場合、次に、計測RTTが、初期RTTの一定倍(例えば2倍)を超過しているか否かを判定する(ステップ1604)。初期RTTの一定倍を超過していない場合は、ステップ1602の処理を実施する。初期RTTの一定倍を超過している場合は、送信帯域制御部715は、第3の制御モードである通常TCPと同等のスピードで帯域を増加させる(ステップ1605)。例えば、新たな制御帯域(token)=元の制御帯域(token)+最大セグメントサイズMSS×8/RTTなどとする(ステップ1605)。これにより、平均RTTと初期RTTの比率に基づいて、増加速度を決定し、決定された増加速度を第一の制御モードと、第2の制御モードとの中間の第3の制御モードとして送信帯域制御を行う通信装置が実現される。
 上述したように、計測RTTが、初期RTTの一定倍(例えば2倍)を超過しているときに、帯域増加速度を通常TCPと同等にする処理を加える。ネットワークの輻輳が検出できていなくても、RTTが増加し始めた早い段階から、帯域増加速度を低下させることで、回線帯域の使いすぎを防止でき、帯域の公平利用が図ることができる。
 図16Cには、ステップ1407における帯域増加処理の別のフローチャート図を示す。図16Bに分岐処理を一つ加えた例を示す。
 図16Bを用いて説明したステップ1604とステップ1602の間に、新たに分岐処理(ステップ1615)が加わり、ステップ1602とは別の処理(ステップ1616)を実施するフローが加わる。それ以外は、図16Bと同様である。
 ステップ1604において、計測RTTが、初期RTTの一定倍(例えば2倍)を超過していない場合、次に、現在の制御帯域(token)が、輻輳が検出されない状態になった直近の制御帯域t_token535を超過しているか否かを判定する(ステップ1615)。超過していない場合は、ステップ1602(第2の制御モード)の処理を実施する。超過している場合は、ステップ1602(第2の制御モード)よりは緩やか制御モードだが第3の制御モードより急である第4の制御モードにより、帯域を急に増加させる(ステップ1616)。例えば、新たな制御帯域(token)=係数β×元の制御帯域(token)などとする(ステップ1616)。これにより、輻輳が検出されない状態になった直近の送信帯域に基づいて、増加速度を決定する通信装置が実現される。
 上述したように、現在の制御帯域(token)が、輻輳が検出されない状態になった直近の制御帯域t_token535を超過したときに、帯域の増加速度を緩やかにする処理を加える。ネットワークの輻輳が検出できていなくても、ネットワークの輻輳が発生する可能性が高い段階から、帯域増加速度を低下させることで、回線帯域の使いすぎを防止できる。 なお、通信装置101の送信帯域制御部150や、図1の通信装置101に対応する通信装置200の送信帯域制御部715では、第一ないし第4の制御モードを搭載し、図16A-Cの処理のいずれか一を実行してもよい。また、第一ないし第4の制御モードのうち少なくとも2種類の制御モードが、搭載、あるいは実行可能な状態で設定された通信装置であってもよい。ただし、第一の制御モードを実行可能な状態に設定されていない場合、増加率の小さい制御モードを実行する期間が所定の期間経過した後(例えば、現在時刻と帯域増加開始時刻との差>T)、送信帯域制御部715(図1の150)は、他の制御モードに図16の条件で変更してもよい。また、各制御モードは、通信装置200の不揮発性記憶媒体にプログラムとしてそれぞれ格納されていてもよい。図16A-Cで説明した4種類の制御モードのうち、2以上の制御モードの設定を、管理端末等から通信装置が実行可能な状態に設定されてもよい。2以上の制御モードを用いて、所定の条件に応じて増加率を増減する送信帯域制御を行い、他の通信との帯域の公平利用がはかれる。また、図16A-Cの1601の、「フレンドリモード有効」かどうかの判断は省略してもよい。
以上送信帯域制御部715が行う送信帯域の増加するための制御モードについて説明した。
(通信モードを変更する処理)
 以下、独自TCP対応の通信装置が、データ通信を開始する場合、対向装置が独自TCP対応か否かで、通信モードを変更する例を説明するが、特に断りのない限り、図1の通信装置100や図2の通信装置のほか上述の実施例の構成と同様である。
 図18のシーケンス図と、図19~図20のフローチャート図と、図23のテーブルフォーマット図を用いて、TCP制御部707/703が状態テーブル212に記載する通信モード(フレンドリモードfriendly_mode532またはワンウェイモードone-way_mode533)を決定する方法の詳細を説明する。
 初めに、図23を用いて、モード/最低帯域指定テーブル740のフォーマットについて説明する。
 モード/最低帯域指定テーブル740は、送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートの組合せ毎に、フレンドリモードの有効または無効と、最小帯域を指定したエントリを複数個備える。
 図7Aに示すユーザ端末741は、送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートの組合せ毎に、フレンドリモードの有効または無効と、最小帯域を指定する。送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートのうち、任意の値をとる項目については、Anyなどと指定する。任意の組合せに対するデフォルト動作を指定したい場合は、送信IP/サブネットと宛先IP/サブネットと送信ポートと宛先ポートの全てをAnyなどと指定した上で、フレンドリモードの有効または無効と、最小帯域を指定すればよい。特定のネットワーク宛の通信について、フレンドリモードの有効または無効と、最小帯域を指定したい場合は、他の送信IP/サブネットと送信ポートと宛先ポートはAnyなどとしたうえで、宛先IP/サブネットと、フレンドリモードの有効または無効と、最小帯域を指定する。特定のネットワーク元の特定の送信ポート番号の通信について、フレンドリモードの有効または無効と、最小帯域を指定したい場合は、宛先IP/サブネットと宛先ポートをAnyなどとした上で、送信IP/サブネットと送信ポートと、フレンドリモードの有効または無効と、最小帯域を指定する。
 TCP制御部707/703は、SYNパケットまたはSYNACKパケットを受信してコネクションを確立する時に、モード/最低帯域指定テーブル740から一致するエントリを上から検索して、一致するエントリが有る場合に、エントリ指定の最小帯域を、状態テーブル212のmin_token535に記載する。更に、送信帯域制御部715が、状態テーブル212のmin_token535に基づいて、min_token535を下回らないように制御帯域(token)を制御する。これにより、各TCP通信の最低帯域を、外部から予め定めることが出来るようになる。
 図18Aには、通信を自発的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP対応の時に、通信モードを決定するシーケンス図を示す。
 通信装置1801(独自TCP対応)は、対向の通信装置(独自TCP対応)1802に対して、独自のオプション番号を持つSYNパケット1803を送信する。対向の通信装置(独自TCP対応)1802は、独自のオプション番号を持つSYNパケット1803を受け取ると、独自のオプション番号を持つSYNACKパケット1804を返信する。通信装置1801(独自TCP対応)は、対向の通信装置(独自TCP対応)1802から、独自のオプション番号を持つSYNACKパケット1804を受け取ると、SYNACKパケット1804のIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索する。一致するフレンドリモード有効のエントリがある場合は、状態テーブル212のフレンドリモード532を有効にする(1805)。
 図18Bには、通信を自発的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP非対応の時に、通信モードを決定するシーケンス図を示す。
 通信装置1801(独自TCP対応)は、対向の装置(独自TCP非対応)1806に対して、独自のオプション番号を持つSYNパケット1803を送信する。対向の装置(独自TCP非対応)1806は、独自のオプション番号を持つSYNパケット1803を受け取ると、独自のオプション番号を持たないSYNACKパケット1807を返信する。通信装置1801(独自TCP対応)は、対向の装置(独自TCP非対応)1806から、独自のオプション番号を持たないSYNACKパケット1807を受け取ると、状態テーブル212のone-way_mode533とフレンドリモード532を有効にする(1808)。
 図18Cには、通信を受動的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP対応の時に、通信モードを決定するシーケンス図を示す。
 通信装置1801(独自TCP対応)は、対向の通信装置(独自TCP対応)1802から、独自のオプション番号を持つSYNパケット1809を受信すると、独自のオプション番号を持つSYNACKパケット1810を返信する。更に、SYNパケット1809のIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索する。一致するフレンドリモード有効のエントリがある場合は、状態テーブル212のフレンドリモード532を有効にする(1811)。
 図18Dには、通信を受動的に開始する通信装置(独自TCP対応)が、対向装置が独自TCP非対応の時に、通信モードを決定するシーケンス図を示す。
 通信装置1801(独自TCP対応)は、対向の装置(独自TCP非対応)1806から、独自のオプション番号を持たないSYNパケット1812を受信すると、独自のオプション番号を持たないSYNACKパケット1813を返信する。更に、状態テーブル212のone-way_mode533とフレンドリモード532を有効にする(1814)。
 以上が、対向装置が、独自TCP対応か非対応かで、通信モードを決定するためのシーケンス図を説明した。なお、独自TCP非対応である対向装置は、例えば、図1のルータ186等の通信装置、計算機131や123である。
 図19には、図18A-Dに対応する、通信を自発的に開始する通信装置が、通信モードを決定するフローチャート図を示す。
 通信装置1801(独自TCP対応)が、自発的に通信を開始すると(ステップ1901)、TCP制御部703は、初めに特定のオプション番号を持つSYNパケットを送信する(ステップ1902)。対向装置からSYNACKパケットを受信すると(ステップ1903)、次に、TCP制御部703/707は、SYNACKパケットが特定のオプション番号を持つか否かを判定する(ステップ1904)。特定のオプション番号が有る場合は、SYNACKパケットのIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索して、一致するフレンドリモード有効のエントリがあるか否かを判定する(ステップ1906)。一致するフレンドリモード有効のエントリが無い場合は、TCP制御部703/707は、そのまま通信を確立する(ステップ1908)。一致するフレンドリモード有効のエントリが有る場合は、状態テーブル212のフレンドリモード532を有効にする(ステップ1907)。また、ステップ1904において、特定のオプション番号が無い場合は、状態テーブル212のone-way_mode533を有効にする(ステップ1905)。その後、強制的にフレンドリモードを有効にしてもよいし(ステップ1907)、ステップ1906を実施して、モード/最低帯域指定テーブル740の検索結果に基づいて、状態テーブル212のフレンドリモード532の有効/無効を決めても良い。なお、状態テーブル212のフレンドリモード532やone-way_mode533は、デフォルトでは無効である。これにより、送信帯域の増加方法を適用するTCP通信を、外部から予め定める通信装置が実現される。
 図20には、通信を受動的に開始する装置が、通信モードを決定するフローチャート図を示す。
 通信装置1801(独自TCP対応)が、受動的に通信を開始すると(ステップ2001)、初めにSYNパケットを受信して(ステップ2002)、通信を開始する(ステップ2003)。次に、SYNパケットが特定のオプション番号を持つか否かを判定する(ステップ2004)。特定のオプション番号が有る場合は、SYNパケットのIPヘッダ410とTCPヘッダ420に記載の送信IPアドレス413と宛先IPアドレス414と送信ポート番号421と受信ポート番号422を用いて、モード/最低帯域指定テーブル740から一致するエントリを上から検索して、一致するフレンドリモード有効のエントリがあるか否かを判定する(ステップ2006)。一致するフレンドリモード有効のエントリが有る場合は、状態テーブル212のフレンドリモード532を有効にする(ステップ2007)。また、ステップ2004において、特定のオプション番号が無い場合は、状態テーブル212のone-way_mode533を有効にする(ステップ2005)。その後、強制的にフレンドリモードを有効にしてもよいし(ステップ2007)、ステップ2006を実施して、モード/最低帯域指定テーブル740の検索結果に基づいて、状態テーブル212のフレンドリモード532の有効/無効を決めても良い。なお、状態テーブル212のフレンドリモード532やone-way_mode533は、デフォルトでは無効である。通信モードが定まると、次に、one-way_mode533が有効か否かを判定する(ステップ2008)。one-way_mode533が有効な場合は、特定のオプション番号を持つSYNACKパケットを対向装置へ送信する(ステップ2009)。one-way_mode533が無効な場合は、特定のオプション番号を持たないSYNACKパケットを対向装置へ送信する(ステップ2010)。SYNACKパケットを送信すると、通信確立する(ステップ2011)。これにより、送信帯域の増加方法を適用するTCP通信を、外部から予め定める通信装置が実現される。
 上述の図23のテーブルフォーマットと、図18に示すシーケンスと、図19~図20に示すフローチャートを用いて、通信モードを決定することで、フレンドリモードにする通信を、外部から予めコネクション毎にユーザが指定することができる。更に、TCP通信の開始時に対向装置から特定の値を持つオプション情報が送付されないときに、フレンドリモードを強制的に適用することが可能となる。
(通信モードに応じて廃棄率の計算の仕方を変える)
 以下、実施例2において、図21のフローチャート図と、図22のシーケンス図を用いて、送信帯域制御部715が、通信モードに応じて廃棄率の計算処理の詳細を説明する。
 図22には、独自TCPと通常TCPのパケット廃棄が起きたときの再送方法の差異を説明するためのシーケンス図を示す。左側に通常TCPの再送制御方式を、右側に独自TCPの再送制御方式を示す。
 通常TCPでは、ACKパケットのTCPオプションヘッダ430内のleft_edge_1~4(433、435、437、439)、right_edge_1~4(434、436、438、440)には、どこからどこまで部分的に受信済であるかを最大4箇所記載して、部分的確認応答(Selective ACK(SACK))用に用いる。一方、独自TCPでは、TCPオプションヘッダ430内のleft_edge_1~4(433、435、437、439)、right_edge_1~4(434、436、438、440)には、どこからどこまで部分的に再送してほしいかを最大4箇所記載して、部分的未確認応答(Negative ACK(NACK))用に用いる。
 通常TCPでは、送信計算機2201から受信計算機2202へ送った12個のデータパケットA~L(2205)のうち、B、D、F、H、Jが途中で廃棄されたとすると、TCPオプションヘッダ430に書き込める受信済み箇所が最大4箇所までである制約から、I以降に送ったパケットに対する確認応答をこの時点では送信計算機2201に送ることができない(2209)。送信計算機は、A~Iまでの部分的確認応答を記載した確認応答パケット(2209)を用いて、パケットA~Iのうち廃棄されたパケットB、D、F、Hを再送する(2206)。受信計算機2202は、再送パケット(2206)を受信してから、パケットI以降の部分的確認応答を記載した確認応答を返信する(2212)。送信計算機2201は、パケットI以降の部分的確認応答を記載した確認応答(2212)を受信してから、パケットI以降に廃棄されたパケットJを再送することができる(2207)。一方、独自TCPでは、送信計算機2203から受信計算機2204へ送った12個のデータパケットA~L(2208)のうち、B、D、F、H、Jが途中で廃棄されたとしても、A~Jまでの再送してほしい箇所をTCPオプションヘッダ430内のleft_edge_1(433)とright_edge_1(434)へ逐一書き込んでから、部分的未確認応答用(NACK)のACKパケットを返信する(2211)。各再送要求箇所は、1つのNACKパケットにだけ書き込まれる。送信計算機2203は、部分的未確認応答用(NACK)のACKパケット(2211)を受信すると、TCPオプションヘッダ430に記載された再送要求箇所B、D、F、H、Jを再送する(2210)。ロスが大量に発生したときでも、一度で再送が完了するため、通信時間が短縮し、帯域が向上する。つまり、送信計算機と受信計算機の間に2台の通信中継装置(プロキシ装置)を設置し、受信計算機側のプロキシ装置が送信計算機側のプロキシ装置に対して廃棄箇所を全て逐一フィードバック通知する。例えば、送信計算機側のプロキシ装置は、受信計算機側のプロキシ装置からフィードバック通知された廃棄箇所を再送すると共に、基準時刻以降の再送帯域や廃棄帯域と、基準時刻以前の送信帯域とに基づいて、特定の宛先に対するデータ送信帯域とデータ再送帯域の総和を増減させる。それにより、廃棄率に依存しない通信を実現することができる。
 上述のように、通常TCPでは、SACKを用いるため、対向装置が通常TCPである場合は、SACKを用いる必要がある。更に、廃棄箇所が最大4個までしか通知されないため、再送帯域を用いて廃棄率を計算してしまうと、廃棄箇所が多いときに、誤差が大きくなってしまう。そのため、対向装置が通常TCPである場合は、廃棄率の計算方法を変え、送信帯域を制御する必要がある。
 図21には、通信モードに応じて廃棄率の計算方法を変えるフローチャート図を示す。
 まず、状態テーブル212のone-way_mode533が有効か否かを判定する(ステップ2101)。one-way_mode533が無効な場合は、対向装置が独自TCPに対応しているということなので、直近の再送数とRTT前の送信数、または、直近の再送帯域rtsとRTT前の制御帯域old_tokenを用いて、再送率を計算し、廃棄率として利用する(ステップ2105)。一方、one-way_mode533が有効な場合は、重複ACKを受信中か否かを判定する(ステップ2102)。重複ACKを受信していない場合は、廃棄率0とする(ステップ2103)。重複ACKを受信している場合は、直近のACK受信数とRTT前の送信数、または、直近の受信帯域rcvとRTT前の制御帯域old_tokenを用いて、廃棄率を計算する(ステップ2104)。これにより、対向装置から特定の値を持つオプション情報が送付されないときに限り、送信帯域とACK受信数の履歴を用いて廃棄率を推定し、推定結果に基づいて帯域制御を行う送信帯域制御部を備える通信装置200が実現される。
 上述のように、本実施例での通信装置は、TCP通信の開始時に対向装置から特定の値を持つオプション情報が送付されないときに、即ち、対向装置が独自TCPに対応していないときに、送信帯域とACK受信数の履歴を用いて廃棄率を推定することで、NACKを用いなくても廃棄率を推定する。これにより、独自TCPが帯域制御に用いる廃棄率の誤差を少なくすることができ、上述のボトルネック帯域の推定が容易となる。
 なお、実施例2の独自TCP対応の通信装置は、実施例1の構成を前提とした通信装置であってもよい。また、図16の第一ないし第4の制御モードのうち、少なくとも一が搭載されてある、通信装置であってもよい。
上述の実施例のように、本願明細書で開示される他の態様は、下記のとおりである。
TCP通信の送信帯域を制御する通信装置が、前記TCP通信において輻輳が検出されず、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、前記TCP通信の送信帯域を線形的に増加させる手段と、前記の一定の期間が過ぎた後、送信帯域を非線形的に増加させる手段と、前記TCP通信において、廃棄率や再送率の変化率を用いて輻輳を検出する手段と、送信帯域と再送帯域の過去の履歴を用いて再送率とその変化率を推定する手段と、送信帯域とACK受信数の過去の履歴を用いて廃棄率とその変化率を推定する手段と、輻輳を検出したときに、送信帯域と再送帯域とACK受信数の過去の履歴を用いて、送信帯域を減少させる手段と、を備える。
 上述の態様により、通常のTCPを用いた通信と、独自TCPを用いた通信が、同一の通信回線を共有する場合でも、独自TCPを用いた通信が、回線帯域を占有することを防ぎ、通常のTCPを用いた通信が通信帯域を確保することが可能となる。
 また、本発明の別の態様によると、
 LAN側とWAN側の複数のTCP通信を中継する通信装置が、各TCP通信の送信帯域を制御する帯域制御部と、各TCP通信の受信確認済みのデータ箇所の履歴を記録する状態テーブルと、各TCP通信における送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴を記録する帯域テーブルと、を有し、前記帯域制御部が、状態テーブルに記載の送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴と、状態テーブルに記載の受信確認済みのデータ箇所の履歴と基づいて、TCP通信の輻輳の有無と、受信確認済みのデータ箇所が更新中か否かを判定し、輻輳が検出されず、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、TCP通信の送信帯域を線形的に増加させ、前記の一定の期間が過ぎた後、TCP通信の送信帯域を非線形的に増加させる通信装置が提供される。
101、102 通信装置
110、120、130 ネットワーク
111、121、131 計算機
190、191、192 回線
200 通信装置
715 送信帯域制御部

Claims (15)

  1. ネットワークに接続される第一の通信装置であって、
    前記第一の通信装置から前記ネットワークを介して第二の通信装置に送信されるパケットに関する帯域をインターバル毎に管理し、
    前記管理される現在のインターバルの帯域及び過去のインターバルにおける帯域に基づいて、前記現在のインターバルよりも後のインターバルにおけるパケットを送出するための制御帯域を増加させる場合、
    所定の期間は、第一の増加率で制御帯域を増加させ、前記所定の期間経過後は、第一の増加率よりも高い、第二の増加率で前記制御帯域を増加させる送信帯域制御部と、
    前記制御帯域に従って、パケットを前記ネットワークに送出する送信部と、を有する、ことを特徴とする第一の通信装置。
  2. 請求項1記載の通信装置であって
    前記送信されるパケットの廃棄状況が所定の条件に満たない場合、
    前記送信帯域制御部は、前記制御帯域を前記所定の期間経過するまでは、線形的に増加させ、前記所定の期間経過後は、非線形的に増加させる、ことを特徴とする、通信装置。
  3.  請求項2記載の通信装置であって、
    前記所定の条件は、廃棄率が所定の閾値に達する場合であり、
    前記所定の条件を満たさない場合は輻輳未検出と判定し、前記輻輳未検出の場合、前記送信帯域制御部は、前記送信されるパケットのうち未受信の箇所を示す情報と、前記送信されるパケットの受領確認応答とを含む通知の受領に応じて、制御帯域を増加させる、ことを特徴とする、通信装置。
  4.  請求項1ないし4記載の通信装置であって、
    各インターバル間の送信帯域及び再送帯域それぞれの比較結果に基づいて輻輳か否かを検出する、ことを特徴とする通信装置。
  5.  請求項1ないし4に記載の通信装置であって、
     前記送信帯域制御部は、送信帯域と再送帯域と前記受領確認応答の受信数の過去の履歴を用いて廃棄率または再送率とそれらの変化率を推定して、
     輻輳を検出したときに、送信帯域と再送帯域と前記受信数の過去の履歴を用いて、送信帯域を減少させる、ことを特徴とする通信装置。
  6.  請求項1ないし5記載の通信装置であって、
    前記通信装置は、TCP通信により前記パケットを送信し、
    前記所定の期間が、前記TCP通信におけるRTTと送信帯域の過去の履歴によって定まることを特徴とする通信装置。
  7.  請求項1ないし6記載の通信装置であって、
     前記送信帯域制御部は、現時点よりも過去のインターバルにおいて、輻輳未検出で送信帯域の最大値を超えたか否かで、増加速度を決定することを特徴とする通信装置。
  8.  請求項1ないし7記載の通信装置であって、
     前記送信帯域制御部は、前記所定の期間経過後は、指数的に増加させることを特徴とする通信装置。
  9.  請求項1ないし8記載の通信装置であって、
    前記通信装置は、前記計算機間のTCP通信により前記パケットを送信し、
    前記TCP通信における平均RTTと初期RTTの比率に基づいて、増加速度を決定することを特徴とする通信装置。
  10.  請求項1ないし9記載の通信装置であって、
    TCP通信に基づく計算機間のデータ転送を中継し、前記データ転送を行うTCP通信のうち、所定のTCP通信に対して前記送信帯域制御部による送信帯域制御を適用し、他のTCP通信については、送信帯域制御を適用しない、ことを特徴とする通信装置。
  11. 請求項10記載の通信装置であって、通信装置が中継するUDPパケット及びARPパケットは、前記送信帯域制御部での送信帯域制御を適用しない、ことを特徴とする通信装置。
  12. 請求項1記載の通信装置であって、
    前記送信部は、前記パケットを送信するための通信を確立する確立要求パケットを送信し、
    確立要求パケットに対する受信される応答パケットに基づいて、前記パケットに対して、
    前記送信帯域制御部による帯域制御を適用するか、否かを決定する、ことを特徴とする、
    通信装置。
  13.  請求項12に記載の通信装置であって、
     前記確立要求パケットは、前記TCP通信の開始時に送信され、
    銭応答パケットに対向装置から特定の値を持つオプション情報が含まれない場合、前記送信帯域制御部による帯域制御を適用することを特徴とする通信装置。
  14.  請求項13に記載の通信装置であって、
     前記TCP通信の開始時に対向装置から特定の値を持つオプション情報が送付されないときに限り、送信帯域とACK受信数の履歴を用いて廃棄率を推定することを特徴とする通信装置。
  15.  複数の計算機に接続される第一のネットワークと広域網である第2のネットワークとに接続される複数のTCP通信を中継する通信装置が、
     各TCP通信の送信帯域を制御する帯域制御部と、
     各TCP通信の受信確認済みのデータ箇所の履歴を記録する状態テーブルと、
     各TCP通信における送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴を記録する帯域テーブルと、
    を有し、
     前記帯域制御部が、状態テーブルに記載の送信帯域と制御帯域と受信帯域と再送帯域の過去の履歴と、状態テーブルに記載の受信確認済みのデータ箇所の履歴と基づいて、TCP通信の輻輳の有無と、受信確認済みのデータ箇所が更新中か否かを判定し、輻輳が検出されず、受信確認済みのデータ箇所が更新中の状態になってから一定の期間は、TCP通信の送信帯域を線形的に増加させ、前記の一定の期間が過ぎた後、TCP通信の送信帯域を非線形的に増加させる、ことを特徴とする通信装置。
PCT/JP2012/077755 2012-02-24 2012-10-26 通信装置 WO2013125096A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US14/241,106 US9231829B2 (en) 2012-02-24 2012-10-26 Communication device
CN201280042248.3A CN103858404B (zh) 2012-02-24 2012-10-26 通信装置
JP2014500864A JP5651805B2 (ja) 2012-02-24 2012-10-26 通信装置
EP12869519.4A EP2819353A4 (en) 2012-02-24 2012-10-26 COMMUNICATION DEVICE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012-038157 2012-02-24
JP2012038157 2012-02-24

Publications (1)

Publication Number Publication Date
WO2013125096A1 true WO2013125096A1 (ja) 2013-08-29

Family

ID=49005297

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/077755 WO2013125096A1 (ja) 2012-02-24 2012-10-26 通信装置

Country Status (5)

Country Link
US (1) US9231829B2 (ja)
EP (1) EP2819353A4 (ja)
JP (1) JP5651805B2 (ja)
CN (1) CN103858404B (ja)
WO (1) WO2013125096A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015037080A1 (ja) * 2013-09-11 2015-03-19 株式会社日立製作所 通信装置および方法、通信処理プログラム
WO2015107806A1 (ja) * 2014-01-15 2015-07-23 株式会社日立製作所 通信装置
JP2017526223A (ja) * 2014-06-25 2017-09-07 ホアウェイ・テクノロジーズ・カンパニー・リミテッド データ送信方法及びデバイス
WO2019244966A1 (ja) * 2018-06-22 2019-12-26 日本電気株式会社 通信装置、通信方法及びプログラム

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150072512A (ko) * 2013-12-19 2015-06-30 한국전자통신연구원 단방향 지연을 제어하는 프레임 전송 방법 및 장치
CN104754003B (zh) * 2013-12-30 2019-01-08 腾讯科技(深圳)有限公司 传输数据的方法及系统
JP6248638B2 (ja) * 2014-01-06 2017-12-20 富士通株式会社 通信端末、プログラム、及び通信方法
JP2015195511A (ja) * 2014-03-31 2015-11-05 富士通株式会社 パケット解析プログラム、パケット解析装置およびパケット解析方法
US10080231B2 (en) * 2015-06-16 2018-09-18 Avaya Inc. Channel bandwidth optimization for dynamic network conditions
DE112015007093B4 (de) * 2015-11-05 2022-02-17 Mitsubishi Electric Corporation Kommunikationsvorrichtung und kommunikationsverfahren
US9813299B2 (en) * 2016-02-24 2017-11-07 Ciena Corporation Systems and methods for bandwidth management in software defined networking controlled multi-layer networks
US10587526B2 (en) * 2016-05-30 2020-03-10 Walmart Apollo, Llc Federated scheme for coordinating throttled network data transfer in a multi-host scenario
CN109905327B (zh) * 2017-12-11 2021-05-07 网宿科技股份有限公司 一种无线网络数据传输方法、发送端及接收端
CN109039932B (zh) * 2018-08-03 2022-07-15 网宿科技股份有限公司 服务器及其过载控制方法
US11599644B2 (en) 2019-05-17 2023-03-07 Walmart Apollo, Llc Blocking insecure code with locking
CN111935025B (zh) * 2020-07-08 2023-10-17 腾讯科技(深圳)有限公司 一种tcp传输性能的控制方法、装置、设备和介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007092901A2 (en) 2006-02-07 2007-08-16 Asankya Networks, Inc. Systems and methods of improving performance of transport protocols
JP2009027303A (ja) * 2007-07-18 2009-02-05 Univ Of Electro-Communications 通信装置および通信方法
JP2009077036A (ja) * 2007-09-19 2009-04-09 Nec Corp 通信装置および通信方法
WO2011033894A1 (ja) 2009-09-16 2011-03-24 株式会社日立製作所 端末間の通信を高速化する通信装置および通信システム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4827652B2 (ja) * 2006-08-10 2011-11-30 富士通株式会社 中継装置、中継方法および中継プログラム
CN100553230C (zh) * 2007-05-21 2009-10-21 中南大学 一种用于高速网络中的协同工作式拥塞控制方法
CN101557607A (zh) * 2009-05-15 2009-10-14 东南大学 无线传感器网络中汇聚节点的传输控制方法
CN101860895B (zh) * 2010-06-11 2012-12-19 上海海维工业控制有限公司 一种改进的aimd拥塞控制方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007092901A2 (en) 2006-02-07 2007-08-16 Asankya Networks, Inc. Systems and methods of improving performance of transport protocols
JP2009526494A (ja) * 2006-02-07 2009-07-16 アサンキア ネットワークス, インコーポレイテッド トランスポートプロトコルの性能を改善するシステムおよび方法
JP2009027303A (ja) * 2007-07-18 2009-02-05 Univ Of Electro-Communications 通信装置および通信方法
JP2009077036A (ja) * 2007-09-19 2009-04-09 Nec Corp 通信装置および通信方法
WO2011033894A1 (ja) 2009-09-16 2011-03-24 株式会社日立製作所 端末間の通信を高速化する通信装置および通信システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2819353A4

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015037080A1 (ja) * 2013-09-11 2015-03-19 株式会社日立製作所 通信装置および方法、通信処理プログラム
WO2015107806A1 (ja) * 2014-01-15 2015-07-23 株式会社日立製作所 通信装置
US9882820B2 (en) 2014-01-15 2018-01-30 Hitachi, Ltd. Communication apparatus
JP2017526223A (ja) * 2014-06-25 2017-09-07 ホアウェイ・テクノロジーズ・カンパニー・リミテッド データ送信方法及びデバイス
US10104578B2 (en) 2014-06-25 2018-10-16 Huawei Technologies Co., Ltd. Data transmission method and device
WO2019244966A1 (ja) * 2018-06-22 2019-12-26 日本電気株式会社 通信装置、通信方法及びプログラム
JPWO2019244966A1 (ja) * 2018-06-22 2021-06-24 日本電気株式会社 通信装置、通信方法及びプログラム
US11588736B2 (en) 2018-06-22 2023-02-21 Nec Corporation Communication apparatus, communication method, and program

Also Published As

Publication number Publication date
EP2819353A1 (en) 2014-12-31
US20140355442A1 (en) 2014-12-04
JPWO2013125096A1 (ja) 2015-07-30
CN103858404B (zh) 2016-11-09
JP5651805B2 (ja) 2015-01-14
CN103858404A (zh) 2014-06-11
US9231829B2 (en) 2016-01-05
EP2819353A4 (en) 2015-05-20

Similar Documents

Publication Publication Date Title
JP5651805B2 (ja) 通信装置
JP5816718B2 (ja) 通信装置、通信システム、およびデータ通信の中継方法
JP5258938B2 (ja) 通信装置
US8169911B2 (en) Method for transmitting a data stream with anticipation of acknowledgments, correspondence input device and computer-readable storage medium
US8843654B2 (en) Data packet transfer over wide area network in fast and reliable manner
EP1771742B1 (en) High performance tcp for systems with infrequent ack
JP5005003B2 (ja) トンネルのトランスポートチャネル上のデータストリームの送信を管理する方法、対応するトンネル終点及びコンピュータ読み取り可能な記憶媒体
JP4702151B2 (ja) ネットワーク中継装置およびネットワーク通信システム
JP2007534194A (ja) パケットを再配列する際のtcp性能の改善
JPWO2008023656A1 (ja) 通信装置
JP5264966B2 (ja) 通信装置
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) 通信装置および通信システム
CN104683259A (zh) Tcp拥塞控制方法及装置
JP4506430B2 (ja) アプリケーションモニタ装置
WO2015022809A1 (ja) 通信装置及び送信帯域制御方法
JP4853862B2 (ja) 通信装置
JP2014135575A (ja) 通信装置、及び、送信帯域の制御方法
KR101396785B1 (ko) 네트워크 장치에서 tcp 기능을 수행하는 방법

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: 12869519

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014500864

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2012869519

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 14241106

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE