JP2008536339A - Network for guaranteed services with virtually no congestion: external Internet NextGenTCP (square wave) TCP friendly SAN ready-to-run implementation - Google Patents

Abstract

  Does not require the use of existing QoS / MPLS techniques, does not require any switch / router software in the network to be modified or contributed to achieve end-to-end performance results, and TCP / IP protocol for immediate ready implementation on the external Internet of a virtually congested guaranteed service-enabled network that does not require unrestricted bandwidth provision on all inter-node links And various techniques of simple modifications to the network switch / router configuration associated with other possible protocols.

Description

  [Note: The present invention refers to the entire related published PCT application WO2005053265 previously filed by the same inventor, previously filed patent application, GB 0504782.4, March 8, 2005, See the entire description of GB05509444.6 on May 9, 2005, GB05122221.3 on June 15, 2005, and GB05207066.3 on October 12, 2005 (and / or not yet included in this application) Incorporate that paragraph in the case) and claim its priority. ]

  Currently, implementations such as RSVP / QoS / TAG switching that facilitate multimedia / voice / fax / real-time IP applications over the Internet to ensure quality of service suffer from implementation complexity. In addition, there are multiple vendor implementations such as the use of ToS (type of service field), TAG-based, source IP address, MPLS, etc., and each traversed QoS enabled router has its data packet Before a data packet can be forwarded, all of the above vendor-implemented fields need to be inspected by the switch / router (and therefore need to be buffered / queued).

  Thus, in a terabit link that carries QoS data packets at the maximum transmission rate, imagine that the router examines (and buffers / queues) each incoming data packet, and the various fields above. It takes CPU processing time to check everything (for example, the QoS priority source IP address table itself checked against it may be tens of thousands). Thus, the router manufacturer's specified throughput capacity (with respect to normal data packet forwarding) may not be achieved under heavy QoS data packet load, and some QoS packets may have a total data packet load that is linked to the link bandwidth. Or, even if the data packet does not exceed the normal throughput capacity specified by the router manufacturer, it will incur a large delay or be discarded. Also, the lack of interoperability standards means that the promised ability of some IP technologies to support these QoS value-added services is not yet fully realized.

  In this document, the switch / router traversed by the data packet does not require RSVP / tag switching / QoS functions to ensure better service guarantees than existing QoS implementations of the current state of the art. A method for guaranteeing quality of service for applications such as multimedia / voice / fax / real-time with better / similar end-to-end reception quality on / proprietary Internet segment / WAN / LAN is described. Furthermore, data packets do not necessarily require buffering / queuing to inspect all of the existing QoS vendor implementation fields, thus avoiding the possible discarded or delayed scenarios described above, and It facilitates the total throughput capacity specified by the router manufacturer, while at the same time forwarding these guaranteed service data packets even at the full transmission rate of the link bandwidth.

To reduce congestion and avoidance / prevention better than existing TCP / IP simultaneous multiplicative rate reduction and packet retransmission mechanism at RTO timeout and / or to enable a virtually service free service TCP / IP function And / or changes in the existing TCP / IP stack that are further modified to reduce the packet retransmission timeout, known as timeout and RTO timeout, as the existing simultaneous multiplicative rate has different rate decrease timeout values and packet retransmission timeouts The TCP / IP stack that is separated into separate processes with values is modified as follows:

. Packet retransmission on simultaneous RTO rate decrease and RTO timeout events takes the form of a complete “pause” of packet / data unit transfer and packet retransmission for a specific source-destination TCP flow with RTO TimedOut One TCP flow or a defined number of packets / data units (which can be RTO packets / data units) can be forwarded every full pause interval during the “pause / expanded pause” period. ,
. Simultaneous RTO rate reduction for the source / destination node pair when the acknowledgment of the corresponding packet / data unit transmitted is not received back from the destination receiving TCP / IP stack before the “pause” is introduced The packet retransmission interval is set as follows:

. (A) Non-congested RTT between source / destination node pairs in the network * multiplicand always greater than 1, or non-congested RTT between source / destination node pairs; . . . . . Sum with interval, enough to deal with the delay introduced by
Or (B) the non-congested RTT between the most distant source / destination node pairs in the network with the largest non-congested RTT * always the multiplicand greater than 1, or the most distant in the network with the largest non-congested RTT The sum of the non-congested RTT between the source / destination node pair and the interval sufficient to handle the variable delay introduced by the various components,
Or (C) according to a devised algorithm to deal with delays introduced dynamically from historical RTT values, eg, * multiplied by always greater than 1 or variable delays introduced by various components Or (D) any user-supplied value, eg 200 ms for audio-visual perceptible tolerance, or eg 4 seconds for http web page download permissible tolerance. . . Such. For time-critical audio-visual flows between the most distant source / destination node pairs around the world, the non-congested RTT may be approximately 250 ms, in which case such a long distance time-critical flow. Note that this RTO setting would be the normal audio-visual tolerance period described above and should be acceptable as well as today's intercontinental mobile phone call quality via satellite.

  For example, using a RTO interval value of (A), (B), (C), or (D) above that is capped within the perceptual tolerance limits of 200 ms real-time audio-visual, a virtually uncongested galvan Ted service network performance is achieved.

  . Only "pause", but instead of or in lieu of existing combined simultaneous RTO rate reduction and packet retransmission, one or a defined number of packet / data units during the entire pause interval or The TCP / IP changes described above, which can be transferred during each successive full pause interval, are over the Internet / Internet subset / WAN / LAN, existing TCP / IP over the RTO mechanism. Note that faster and better congestion recovery / avoidance / prevention can be enhanced than simultaneous multiplicative rate reduction, and even a guaranteed-free guaranteed service function can be enabled. It should also be noted that the combined simultaneous RTO rate reduction and packet retransmission of the existing TCP / IP stack can be separated into separate processes with different rate reduction timeout values and packet retransmission timeout values.

  . Also, the TCP / IP changes in the previous paragraph can be made incrementally by an initial few users, but may not necessarily have a rather bad performance impact on the modified “pause” TCP adopters, Packets / data units sent using the modified “pause” TCP / IP are rarely discarded by switches / routers along the route, and are fine tuned / discarded to not cause the packet / data unit to be discarded Note that you can even avoid it. When this change is adopted by the majority or generally, the existing Internet will achieve a guaranteed service function with virtually no congestion and / or along the route by the switch / router due to congestion buffer overflow There is no packet drop.

  As an example, each of all switches / routers in the network / Internet subset / proprietary Internet / WAN / LAN is equivalent to a minimum of s seconds (ie, s seconds * the total physical bandwidth of all previous incoming links) Have a buffer size and / or made so that the RTO timeout or decoupled rate decrease timeout interval of the originating sender source TCP / IP stack is set to the same s seconds or less (this is the audio-visual tolerance or all packets / data units sent from the source's modified TCP / IP will not be discarded due to congestion buffer overflow at the intervening switch / router. Is the larger of the sum of the buffer size equivalents of all intervening nodes in time periods or in seconds, equivalent to the number of nodes traversed in the worst case (preferably this is the required definition Is within the specified tolerance period, or can be made so). Therefore, good practice for intervening node switches / routers that all of the buffer sizes should be at least equal to or greater than the equivalent sender / source modified TCP / IP stack RTO timeout or decoupled rate decrease timeout interval setting. become. The originating sender source TCP / IP stack has a total accumulated buffer delay of the intervening nodes that is greater than or equal to the originating sender TCP / IP stack RTO timeout interval or decoupled rate decrease (herein "pause") timeout interval. Sometimes it has an RTO timeout or decoupled rate decrease timeout, and this RTO timeout or decoupled rate decrease timeout interval value can be set / so within a required defined perceptual tolerance interval.

  This means that a single or defined number of packets / data units transmitted during any pause period / interval will arrive later with a corresponding acknowledgment after an RTO timeout or decoupled rate decrease timeout Even so, especially if it is not allowed to be further excluded or caused by any RTO “pause” event or decoupled rate reduction “pause”. In that case, in the case of worst congestion, the origin sender source TCP / IP stack alternates between “pause” and the normal packet transmission phase each of equal duration → ie the origin sender source TCP / IP stack In the worst case, it should only “halve” its transmission rate, and during the “pause” it will send almost nothing, but if it resumes when the pause stops, the sliding window mechanism Send at the highest speed allowed under.

  In addition, for all TCP / IP stacks or the majority, everything is so modified and a common value for the RTO timeout interval or decoupled rate decrease timeout interval, eg t milliseconds within the defined perceptual tolerance period required. On the Internet / Internet subset / WAN / LAN with t = the non-congested RTT * m multiplicand of the farthest source node / destination node pair in the network, within that Internet / Internet subset / WAN / LAN All packets sent must arrive at the destination experiencing the total accumulated buffer delay along the shorter route of s * number of nodes or (t−non-congested RTT) + t only.

  This contrasts favorably with the RFC implementation of the existing TCP / IP stack, which does not guarantee that the packet will not be discarded, and possibly the transmission It cannot be guaranteed that all packets sent will arrive within a useful defined tolerance period. During a “pause”, the intervening path congestion is cleared and helped by this “pause”, and a single or a small defined number of packets transmitted during this “pause” are modified. In order for the TCP / IP stack to react accordingly, usefully probe the intervening path to see if congestion continues or has stopped.

Next Generation TCP: Further improvements and changes
External Internet node (can also be applied to internal network nodes)
The same decoupled “pause” / transmission rate reduction timeout and actual packet retransmission timeout mechanisms (ACK timeout and packet retransmission timeout) applied to guaranteed service Internet subset / WAN / LAN, as well as external internal It can be applied to cloud / external WAN / external LAN. In this case, the non-congested RTT test (ie, the latest smallest minimum time period variable for the corresponding back ACK received so far) is the known non-congested RTT in the guaranteed service Internet subset / WAN / LAN. Used in place of value.

  . From the received ACK (which can be an ACK for a transmitted normal data packet, ICMP probe, or UDP probe), the latest minimum time period (from the corresponding packet transmission time) of receipt of the ACK is This non-congested RTTest is updated and serves as the most recent estimate of the non-congested RTT value between the source and destination (if the non-congested RTT between the source internet node and the external internet node is actually known) If so, even better). Knowledge can be made about the fact that the furthest non-congested RTT on the earth is 400 ms, for example, and thus the fact that the maximum non-congested RTTest is 400 ms, for example (but both ends are Note that with a small 56K modem bandwidth, and when a large packet is transferred, eg 1500 bytes, it takes about 250 ms for a 1500 byte packet to completely exit or enter the modem. Therefore, it should be preferred to also obtain the time at which the packet actually completes leaving the modem to adjust the non-congested RTTest value accordingly).

. A “pause” is triggered (but its “pause” interval) if the RTT of any packet (derived from its ACK) * a> non-congested RTest (a is always a multiplicand greater than 1) Or allow one or more data packets to pass or allow only probe packets to pass during the extended “pause” interval (s), or rate is a percentage, eg, existing rate (This can be done, for example, via a traffic shaping technique or a congestion window size decrement ...) and / or the most recent / subsequent received ACK Defined time derived as long as the RTT * a of> continues to be> non-congested RTTest or based on the devised algorithm For while, it does not simply increments the window size / congestion window size for subsequent ACK sometimes modified TCP, or any combination of the above,
The rate decrementing implementation directly on the TCP stack is self-evident, but the monitor software / IP forwarding module / proxy TCP. . . Can be implemented through existing rate shaping / rate throttling techniques, or simply mirror the most recent effective window size value for a particular TCP flow (and / or postpone the operation of this mechanism). ) Implement as another window size / congestion window size mechanism for each TCP flow in the monitor software / IP forwarding module / proxy TCP, but the RTT * a of the most recently received ACK for a particular flow is> Do not mirror / stop mirroring the most recent effective window size value as long as / when it remains non-congested RTTest (ie, start this mechanism operation): Recently received ACK RTT * a> non-congested As long as / when it remains a TTest, the monitor software window size / congestion window size value for this particular flow is the most recently mirrored derived / calculated current effective window size of that flow, ie Should be reduced to m% of the smaller of the window size / advertised window size / congestion window size value, eg 95% (Note: the above operation is optionally only t seconds, eg 1 second) Or it can be delayed based on some devised algorithm).

  [Note: When implementing the monitor software, the sender TCP congestion window size is not directly available on Windows platforms without the Windows TCP stack source code, and therefore needs to be derived from the network, hence the sender TCP The current effective window size of the source can be derived (effective window size = min (window size, congestion window size, window size advertised by the receiver). Current effective window size value / congestion window of the current sender TCP source. There are various existing state-of-the-art methodologies in the derivation / approximation of the size value, but as an example we have the congestion window size of the sender TCP source when not overflowing the connection. Can be assumed to be the current transmission rate * non-congested RTTest (ie, by selecting one “distinguished” packet per RTT that monitors its transmission time and its return ACK time. Current transmission rate, current transmission rate = (number of bytes moving between transmission time and back ACK time) / (back ACK time-transmission time), we have the current congestion window size of the sender TCP source Can be assumed to be equal to the number of bytes being moved.

  Another example is analogously the current effective window size / current congestion window size of the sender TCP source, similarly derived by monitoring the total number of bytes transferred by the monitor software within the RTT interval. Can be derived].

In monitor software, the percentage rate decrement may optionally not depend on the derivation / estimation of the current effective window size as described above; instead, the monitor software will instead “pause” (And / or allows one or more packets to be forwarded during this pause interval):
. Effective if the periodically spaced paused interval reaches, for example, a total p * I within 1 second (I is the periodically spaced paused interval in seconds) Thus, congestion window = (1- (p * I)) / one second of current throughput (current effective window size * current RTT).

  . Hence, (P * I) must be equal to 0.05 to provide a 5% rate decrement.

  This “pause” interval may not need to be periodically spaced evenly and / or each “pause” interval may not need to have the same pause duration. .

  Example: If there is a total transmission time of less than 5% during “one or more pauses”, the source-destination bandwidth delay product should now be reduced to the existing value of 0.95. This is because there should now be, for example, 5% fewer non-overlapping RTT intervals within one second to transmit up to the total valid window size data bytes for each non-overlapping RTT interval. . The “pause” interval duration should preferably be set at least equal to the minimum value of non-congested RTTest, but can be smaller if necessary. For example, in a VoIP transmission that sends one sampled packet every 20 ms (assuming it is much smaller than the non-congested RTTest), for example a single “pause” interval duration of 50 ms in one second (ie, Which results in a rate decrement equivalent to a 5% effective window size decrement), for example, five equally spaced periodic “pauses” in one second, where “pause” Each of which has a duration of 10 ms (so as not to introduce long delays in time-critical VoIP packet forwarding), or, for example, 10 equally spaced periodic “pauses” in one second. Each of these “pauses” has a duration of 5 ms. . . . Etc.

  Furthermore, the sender TCP source code can also implement the current effective window size setting, completely utilizing the “pause” method, completely replacing the need for congestion window size settings. With this modified TCP, the current effective window size at any time should be [min (window size, window size advertised by receiver) * ((1- (p * I)) / 1 second)]. It is.

  (Don't repeatedly decrement when continued RACK * a stream of received ACK continues to be> non-congested RTTest: but also, for example, packets sent since the most recent latest rate decrement If the most recently received ACK stream RTT * b (b must be> a) corresponding to is non-congested RTTest, the monitor software window size value / congestion window size value is now The monitor software window size value / congestion window size value that has already been reduced to L% / m%, for example, 90/95% (L% or m%) can be optionally reduced repeatedly {b is It represents a more severe level of congestion or even packet drops than a. The monitoring software can optionally delay the above operation by t seconds, for example 1 second, so that all existing Unmodified TCP will be synchronized in rate decrement}.

  And / or when certain conditions are met, eg, during a period of time based on a devised algorithm, as long as the RTT * a of the most recent / subsequent received ACK of the flow remains> non-congested Do not increment size / congestion window size.

  When using monitor software, TCP, of course, has its own slow start / congestion avoidance / coupled RTO. . . Continue to do. When the monitor software has not yet received an ACK for a transmitted segment, for example, after a very long period of time, eg 1 second. . . Or from sudden halving of the transmission rate of the flow. . . TCP RTO events can be predicted / detected. The monitor software may further choose to decrement its mirrored window size value / congestion window size value, for example to 90% (n%) of the existing value, and / or some devised algorithm During a certain time period derived based on the specific flow's own effective window size / congestion, for example as long as the RTT * a of the most recent / subsequent received ACK remains> non-congested RTTest You can choose not to increment the window size.

  The monitor software can also implement its own packet retransmission timeout, which ensures that the monitor software keeps a copy of the transmitted packet for the dynamic window and resembles TCP. A software module is required, so the monitor software can perform the functions of the above paragraphs much more quickly without having to wait for a TCP RTO display. Hence, the monitoring software can optionally prevent slow ACKs from causing RTO in TCP, for example by spoofing ACKs to TCP, via generated / spoofed ACKs to TCP. TCP can be controlled / paced for example by setting a spoofed ACK with an advertised receiver window size of 0 to “pause” TCP for a period of time, or a spoofed ACK Decrease TCP effective window size by setting the desired value in, and set DUP ACK with Acknowledgment Number field value = latest sent SeqNo value to cause actual packet retransmission Without Let TCP halve the effective window size. . . Etc. The monitor software can optionally delay the above operation by t seconds, for example 1 second, so that all existing unmodified TCPs are synchronized at various rate decrements.

  A variety of different algorithms / different algorithm combinations can be devised instead of those shown / outlined above. Various existing state-of-the-art methods or component methods may be further incorporated as improvements in any of the methods or component methods described herein.

  A modified TCP (or even modified RTP over UDP / even modified UDP...) Flow does not need to be halved in this case. This is because when they are congested and cause a packet drop (during a buffering event), there is no need to increase the rate and, for example, a 10% / 5% decrement of the transmission rate will cause non- (All other existing unmodified TCP flows should guarantee a 50% decrement, but always try to increment the rate and cause another packet drop.) Is). New flows should build their fair share over time. This is a short latency for existing established flows. . . And so on (suitable for VoIP / multimedia) to reflect the existing traditional PSTN call admission schedule.

  In this case, modified TCP / modified RTP over UDP / modified UDP retains its established share or most of its established share of the link bandwidth, but with additional additional congestion. / Does not cause packet drop.

  TCP exponential increase to threshold, linear increase during congestion avoidance after threshold, sliding window / congestion window mechanism. . . Etc. ensure that the bottleneck link congestion begins slowly, so modified TCP and existing unmodified TCP can react accordingly and remove congestion. Modified TCP / Modified RTP over UDP / Modified UDP here is identified by even using a quick burst of enough extra traffic, eg, at a congestion level close to packet drop. It can be ensured that all or selective existing flows traversing the congested link (s) will get a packet drop notification to reduce the transmission rate. The existing unmodified TCP should halve its rate and take a long time to reconstruct the transmission rate that caused the previous congestion, but the modified TCP will be along the link (s) Should retain most of all established shares of bandwidth.

  This most facilitates the incremental adoption of this simple isolated TCP change on the public Internet. The modified sender TCP source achieves higher throughput and reduces its established share of bottleneck link bandwidth in the event of bottleneck link congestion that causes drops (or just physical transmission errors that cause packet drops). At the same time, it preserves fairness between flows (compare with existing TCP that loses half of the established bandwidth in a single packet drop) and does not cause any packet drops by itself. This modified sender source TCP overcomes the existing TCP rate recovery problem caused by only a single packet drop in a high bandwidth long latency network.

  When the sender TCP source traffic originates from an external Internet node / WAN / LAN, the traffic originating from the outside is time stamped (the receiver TCP derives the path transmission time or the one-way transmission delay from the source to the destination) The modified sender source TCP method described above can be adapted to act as a receiver-based method.

  . The origin source timestamp does not need to be accurately synchronized to the receiver. The receiver can ignore the time stamp drift of the source system clock in this case. OTTest (the most recent update estimate of the one-way transmission latency of the received packet from the source to the destination, the current receiver system time when the packet was received-the sender timestamp of the received packet and The smallest value ever derived) is derived at the receiver. All increments of OTT observed in subsequent received packets are the ignorant beginning of congestion along the path (ie, at least one forwarding link along that path is currently fully Means that the sender TCP source now has to trigger a modified rate decrement or “pause” mechanism. Should do. The receiver can signal this to the sender TCP source by:

  . Before returning to the same original advertised window size after an appropriate “pause” or an appropriate “periodic” pause, set the advertised window size to 0 in the return ACK for the appropriate period.

  . The current derivation / estimated effective window size of the sender TCP source (effective window size = min (window size, congestion window size, receiver window size)), for example, the current derivation / sender of the sender TCP source Set 95% of the estimated effective window size to the advertised window size, in which case the sender TCP source will receive a decremented current derivation / estimation where the modified receiver TCP is advertised the same. The effective window size should not be continually incremented for ACKs received within each RTT as long as it continues to ACK using the effective window size, but the advertised receiver window size of the current return ACK is If it is changed later, the increase Does not cause a packet drop, because the sender TCP source has been changed to eventually decrement its effective window size at the next ignorant beginning of congestion along its path Because the receiver TCP guarantees, another possible technique involves the receiver TCP DUPing Ack (sequential 3 DUP ACKs to trigger halving of sender TCP source multiplicative congestion window reduction). .

  . During the initial TCP connection establishment phase, the modified receiver TCP should negotiate with the sender TCP source to have a time stamp option. This receiver-based modified TCP / modified monitor software does not require changing the sender TCP.

  When both sender TCP and receiver TCP are changed with the timestamp option, better and more accurate knowledge of OTT / OTT variation in both directions should be enabled (modified TCP / change Both monitor software can pass OTT knowledge in the direction to each other, so modified TCP / modified monitor software now has better control using OTT rather than RTT For example, if the OTT of the transmitted segment does not indicate congestion but the OTT of the returned ACK indicates congestion, the RTT used in the previous RTT-based method has timed out. However, there is no need to rate decrement / pause, a time stamp option when it is only performed on the sender. RTT-based modified TCP, used in conjunction with, should also allow senders to own OTTest and / or OTT variations of returning ACKs as well and provide better control as well .

  When the modified TCP technique is implemented at both ends of an intercontinental low cable / satellite link / WAN link, it effectively resembles doubling the physical bandwidth of the physical link, and bandwidth utilization of the TCP transmission medium. Note that the degree and throughput should increase.

  Those skilled in the art can make various modifications and changes within the scope of the present principles.

UDP prioritization Giving UDP a higher priority than TCP at each node in the Internet / Internet subset / WAN / LAN → etc., but still the previous existing TCP buffered packets in the node's input queue = > Note that due to buffered delay of UDP packets or even UDP packet drops, UDP traffic will result in UDP drops even when not using more than 100% of the bandwidth of the transport link I want to be.

  1. UDP packets from the UDP input queue that are placed in front of the node's input queue buffer (and / or given priority over the TCP packets even when the TCP packets are already enqueued to the output queue) In front of the output queue) and push all TCP packets towards the end of the queue (thus all TCP packets will drop all UDP packets in the input queue and / or output queue) Router / switch software needs to be upgraded / changed).

  2. Upgrade router / switch software to allow creation of separate UDP input queues (which can be very small) and TCP input queues, UDP queues scheduled to output queues before TCP packets Is done. And / or implement a UDP high priority output queue and a low priority TCP output queue.

  UDP traffic alone may exceed the physical bandwidth of the link, may cause the source sending UDP to reduce the transmission rate or resolution quality, and / or allow all UDP to the router / switch node May cause this resolution reduction process to be performed on the flow (eg, sending only alternating packets of the flow and discarding other alternating UDP packets, or of two (or more) eg VoIP UDP packets Combine data into one packet of the same size but lower resolution quality).

  The node is a variety of UDP / TCP. . . By guaranteeing a minimum ratio of the bandwidth of the forwarding link for a flow such as, TCP incomplete depletion can be guaranteed.

Further changes in bandwidth estimation include the following (and can be used in conjunction with the previously described non-congested RTT / RTTest / RTTbase / OTTest / OTTbase / receiver OTTest methods, thus providing output results: The following techniques, which may require some time, can give enough time to supplement the above method).

  1. For example, a “pause” / rate reduction to prevent queues / packets from being buffered (ie, preempting buffer delay so that all traversed nodes do not introduce any buffer delay) A reasonable interval derived from an algorithm devised for that purpose / rate reduction (according to an devised optimized algorithm) when certain conditions are encountered, such as the link utilization for forwarding reaches 100% The bandwidth, utilization, throughput, queue length, and delay encountered in each traversed node to “pause” only during. . . In order to confirm the above, pipechar, pipechar, traceroute, pathchar, pchar, pathload, bprobe, probe, netest, chirp. . . Use similar methods and similar techniques.

  For example, when the utilization on a particular link (which may include all of UDP, ICMP, and TCP) reaches, for example, 95%, the received ACK window size is not incremented any further, and Only if / when the packet is subsequently discarded, eg decremented by 10% (so that the new flow does not completely “deplete” bandwidth on the particular link) and / or possibly In addition, the window size of each ACK may not be incremented. If a packet is discarded due to a physical transmission error (ie not due to buffer overfill congestion), the link utilization on a particular link along the path is eg 95% (or a specified percentage) When less than utilization, we do not need to stop window size decrement [solves high bandwidth length RTT TCP rate recovery problem]. This most facilitates the incremental adoption of this simple isolated TCP change on the public Internet. New flows (UDP, ICMP, TCP) and / or existing unmodified TCP / RTP over UDP / UDP must now always have at least 5% guaranteed non-depleted bandwidth to always increase . This is because all modified TCP / RTP over UDP / UDP can not increment the transmission rate, for example when the link utilization exceeds 95%, for example. Also, if the link then discards the packet / time, the modified TCP / RTP over UDP / UDP decrements the window size / transmission rate by, for example, 10% (or, for example, x / (x + y) = 0. 1. Periodically pause for interval x before transmitting at the unlimited rate allowed by the transmission medium adjacent to the sending source for period y, ie, eg 10% sliding window or congestion window Equivalent size reduction / rate reduction). Pause during interval x instead of sliding window / congestion window size decrement / rate decrement gives the fastest possible early clearing of the congested buffer at the node and buffer delay at the node along the path Helps keep the value at the very minimum.

  The buffer size requirement here is not at all a very relevant factor for consideration. Perhaps all traffic can be kept at all times within / less than 100% of the available physical bandwidth (need to be buffered subject to very sudden burstiness) Sometimes).

  For VoIP / multimedia (eg, using RTP over UDP / UDP) or VoIP / multimedia as a total traversing the same part of the same route / path, the link exceeds even more than 95% or even 100%, for example When starting, the source VoIP / multimedia can now be transmitted, for example, at a certain percentage, eg, half of the resolution quality, and other traffic increases will return link utilization to eg 95% / 100%. Wait and return the current sudden burst to full resolution quality transmission and / or plus extra resolution, eg 200% or more (using extra redundant erasure coding, etc.) Cause an immediate sudden burst Can discard packets that trigger rate reduction (usually within 1 second in existing RFC TCP implementations) of other TCP flows (modified or unmodified), and other When the flow, eg TCP, is now rate decremented, it immediately returns to 100% original transmission quality (or perhaps the ratio of bandwidth / link / bandwidth used by multimedia / buffer size at node ... , Etc., can still grab as much bandwidth as possible while staying at 200% resolution quality transmission) → guarantees the minimum possible buffer delay of VoIP / multimedia.

  Perhaps VoIP / multimedia can even start with a higher resolution transmission quality (eg, 200% of the normal required resolution using redundant erasure coding, etc.).

  This is useful for all flows because it guarantees as little buffer delay period as possible at the traversed node for all flows. This is to allow an authorized request to discard a flow packet (eg, one packet from each TCP flow to inform the sender of rate decrement) and / or upon detection of eg 95% / 100% link utilization The router software can be upgraded further to do this.

  The above method is based on the existing RIP / BGP router table update packet. . . And / or similar techniques can be used to guarantee minimal or no buffer delay at all nodes, and the upgraded router software performs link preference routing table updates to make certain forwarding For example, 95% / 100% of the links to be preempted. . . And / or propagate it throughout the network, not just adjacent routers (but should be enhanced to allow more frequent real-time rate updates).

  Another next-generation network design is that routers, for example, 95% / 100% utilization of a particular forwarding link (100% utilization should indicate an imminent beginning of packet buffering) and / or link Raw bandwidth / queuing policy / buffer size. . . Signaling to neighboring routers for other configuration details such as (to prevent neighboring routers from increasing the existing transmission rate only to this router / or this forwarding link) and / or updated An devised algorithm that relies on some corresponding “pause” interval x before continuing the unrestricted transmission rate of information or duration y (actually limited only by the link bandwidth between routers) Only a percentage based on per-flow rate decrement / rate shaping for flows traversing the advertised router link. Packets for all TCP flows that require buffering during "rate decrement" / "pause" should only be most of the window size at any one time, and RTP / UDP flows are similarly Can now be buffered → It is now possible that the source congestion avoidance TCP rate limiting mechanism could be eliminated at all! . Does the router change to set the advertised window size field of the ACK back to the sender TCP source to 0 for some duration or periodically for some duration (cause a "pause" or a periodic "pause")? Or even changing / setting the advanced window field value to a decremented percentage of the derived / estimated current effective window size of the sender TCP source (thus resulting in rate limiting of the source traffic) it can. The switch / router on the Internet / Internet subset / WAN / LAN keeps a table of all flow source-destination addresses and / or ports in its latest Seq Number field and / or ACK number field (and / or link). Along with the transfer rate per flow along, the effective window size per flow along the current derived / estimated link, etc.) "Back ACK" and / or "duplicated packet". . . It is only necessary to be able to generate advertised window size updates (e.g., before returning to the existing receiver window size value before "pause") Through the advertised receiver window size of the value that is decremented based on the current source TCP effective window size derived / estimated to “pause” through the advertised receiver window size To inform the source TCP to reduce the rate). Neighboring routers reduce / traffic shape packets destined along the next router's advertised router's link, and neighbors that know a packet IP address can receive routing table entries, RIP / BGP updates, MIB exchange. . . It is scheduled to be routed along the link of the next router notified from. For example, an already periodically paused flow (rate controlled via a periodic “pause”) on an adjacent router that precedes the advertising router is now further “paused” by the affected flow. It should increase the interval length and / or increase the number of “pauses” within that period. Periodic pauses, for example, indicate neighboring routers that show link utilization that has fallen back to a defined period derived from the devised algorithm, e.g., a router that advertises now falls back below a certain percentage, e.g. below 95%. When updating, the frequency / individual pause interval can be stopped or reduced.

  The RED / ECN mechanism can be modified to provide this functionality, i.e., rather than monitoring buffered packets and selectively discarding / notifying the sender RED / ECN is, for example, when usage reaches a certain percentage, eg 95%. . . For example, it can be based on a policy regarding link utilization.

  Based on the above-described bottleneck link utilization estimation technique, usable bottleneck bandwidth estimation technique, bottleneck throughput estimation technique, bottleneck link bandwidth capacity estimation technique, and further based on the non-congested RTT / RTTest / RTTbase / receiver OTTest method It can be incorporated into the rate decrement / pause method described above. Here, to further enhance the rate decrement / pause method described above based on the non-congested RTT / RTTest / RTTbase / receiver OTTest method, a bottleneck link utilization estimation technique, usable bottleneck bandwidth There should be plenty of time to derive / estimate the estimation techniques, bottleneck throughput estimation techniques, bottleneck link bandwidth capacity estimation techniques for good enough accuracy. Various additional techniques to supplement / provide the topology / configuration of routes include SNMP / RMON / IPMON / RIP / BGP. . . Etc. can be included.

  2. Periodic probes are Windows Update probes (to query the receiver window size even if the receiver has not yet advertised the 0 window size) or similar probe packets. . . Or the actual data packet as a periodic probe (if available for transmission). . . Etc., or UDP to a destination with an unused port number (to get a return message that the destination port is unreachable), and / or in addition to this, timestamp options from all nodes can be used. Alternatively, similarly, TCP to a destination with an unused port number (this TCP packet can be a TCP SYNC to an unused port number).

Various notes [Note: If the paused interval totals p * I, for example within one second, effectively, congestion window = (p * I) / one second of current throughput (current effective window size) * Current RTT)]
Upon detection of congestion, time-critical applications can send bursts to cause packet drops, or receivers that detect congestion from timestamps can cause bursts or bursts, possibly in the form of large probes. Can be notified to the server.

  In addition to RTTest techniques for external Internet nodes, the use of bandwidth estimation techniques can be improved along with, for example, receiver processor delay, raw bandwidth, usable bandwidth, buffer size, buffer congestion level, link utilization.

  Receiver-based OTTest does not need to deploy GPS synchronization, only non-congested OTTest, non-congested OTTbase, or known non-congested OTT and OTT monitor variants! ! ! .

Sender-based and / or receiver-based raw bandwidth and throughput estimates-> link utilization Time stamps (sender and echoer) are used so that the sender can block out receivers that handle delay variations.

  The modified TCP / modified monitor software, when paused, optionally optionally sets all newly arrived data segments (ie, ACK flags from the host source TCP that need to be buffered) Instantly generate and send (despite "pause") a pure ACK that does not carry a data payload, corresponding to a piggyback ACK segment or a pure ACK, ignoring normal data segments that do not ACK anything) Can do. All pure ACK (s) generated during this pause / extended pause interval are sent immediately, but in the Seq Number field value, the very first buffered data segment (this is , Which can be a normal data segment or a pure ACK segment with or without the ACK flag set). If the newly arrived segments are pure ACKs, simply buffer them as well and generate / send a pure ACK corresponding to this newly arrived, currently buffered pure ACK Do it! . Forwarding this newly arrived net ACK before other buffered data segments at this time must now be identical to the last sent acknowledgment number to the receiving TCP. May receive a packet having a sequence number larger than the expected sequence number. If the generated pure ACK is sent, the corresponding currently buffered pure ACK can optionally be removed from the buffer and discarded. This is because it does not make sense to send a duplicate pure ACK. A net ACK can instead be generated and a buffered segment with the highest acknowledgment number among all buffered packets in this pause interval / extended pause interval period It can correspond to.

  Modified TCP / modified monitor software optionally includes the URGENT / PSH flag. . . . Etc. can be transferred immediately even during “pause” / expanded “pause”.

  It is also possible to derive the actual rate = number of bytes transmitted after the segment transmission time / ACK timeout. It holds an event list of entries including Seq No, ACK timeout, and the number of bytes in this segment. Or the actual rate = the number of bytes transmitted since the segment's transmission time / (the transmission time of this particular ACK timed-out segment-the transmission time of the last unacknowledged segment on the list, the transmission time in the list If there is no last segment to have = set this ACK timed-out segment + ACK time-out period, or use the actual rate based on the last transmitted segment within the ACK time-out period (probably the actual rate = Ack received, ie, the total number of bytes corresponding to all of these acknowledged segments can also be derived (within RTT or ACK timeout period).

  The receiver base can distinguish between congestion loss and physical transmission error, and can detect the rate, OTT or OTTbase, the beginning of congestion separately and more accurately in each direction. Even better, the sender receives an ACK with a timestamp when the receiver first receives the packet and / or when the receiver last modified a packet (and / or ACK) (eg, IPMP) sent back to the sender. Receive back and receive.

  Note that throughput = window * MSS / RTT bytes / second can also be derived.

  The modified TCP technology implementation for multicast requires implementation / hierarchical coordination in the multicast module of the router.

  The monitor software can better tune if the sender and / or receiver have identified each other's presence, eg via a unique port number establishment. It is possible to switch to the combination.

  When sending / receiving via external nodes, you may not want to “pause”, but when you want to enable this preferred “pause” inclusion, such as when the majority of incremental adoption on the Internet is Is preferred (probably a user-selectable option)! .

  Initially probe for available bandwidth and / or raw bandwidth capacity of the path (corresponding to the bottleneck) so that, for example, 95% of the available bandwidth or 95% of the capacity is immediately utilized TCP window size can be started.

  If the RTT continues to be <ACK timeout, the window size is much faster, eg * 1 / cwnd. . . Etc. can be incremented.

  ACK timeout (and / or actual packet retransmission timeout value) values can be derived dynamically from the returning real-time RTT based on an algorithm devised for this purpose, similar to existing RTO estimation algorithms from historical RTT Please note that.

  In RFCs, DUP ACKs must not be delayed, where we comply by immediately transmitting the generated pure ACK immediately for all buffered ACK packets or simply their highest ACK No. did.

  In order to avoid path rerouting problems that could give false estimates of RTT, we can employ hop-by-hop RTT estimation and bandwidth probing. By using active networking technology for a practical implementation, a section-by-section dialog is performed between adjacent nodes including routers.

  Note: In RFC, the TCP receiver must not generate multiple ACKs for all incoming segments other than for updating the provided window when the receiving application consumes new data.

  Depending on DIFF (RTT, non-congested RTT / RTTest), the window size can be reduced / the “pause” period can be increased. Percentage rate decrement / pause interval length is the size of the buffer delay experienced along the path, eg, OTT-OTTest (or OTT-known non-congested OTT), or RTT-RTTest (or RTT-known non-congested). It can be adjusted according to the congestion (RTT).

  The modified receiver when the modified receiver TCP receives a pure ACK (or even all ACKs) generated by the modified sender TCP for the sender's buffered ACK packet while “pausing”. Optionally / especially generates a byte with a Seq number set to the last ACK number -1, i.e. knows that a modified sender TCP has been received, a return ACK (In this case, it may be necessary to ensure that each and every buffered packet is an individually generated pure ACK, not just an ACK with the highest Seq number). The sender TCP can infer whether or not the generated pure ACK of this 1-byte data is not returned by the receiver by “packet duplication ACK” (in the case where the duplicated packet is not passed to the receiver side application). → then react accordingly (eg reverse path congestion / congestion loss / transmission error or forward congestion / congestion loss / transmission error, in the latter case 1 byte generated You may want to send a data pure ACK again ...).

  Monitor software at both ends, or sender only, or receiver only: Acking the ACK using receiver's latest Seq No (replicated packet) or latest Seq No and 1 byte data or even latest remote ACK number-1 To remove the main cause of RTO or lost ACK, the lost data segment is usually DUP ACK-> fast retransmission).

  Receiver-based: retransmits ACK when ACK is received back and not acknowledged. For example, a DUP ACK (high-speed retransmission) is transmitted to arrive again one second before the first segment transmission time, thereby preventing RTO which causes TCP to re-enter the slow start of CWND = 1. During the preceding RTT interval, of the estimated sender's maximum actual transmission window size (corresponding to the actual rate; this actual transmitting window size can be assumed to be equivalent to all flight packets) As a percentage, the receiver window size can be adjusted dynamically.

  The future RFC of TCP must have one extra Acking ACK field (Acking the ACKs control feedback loop), which completes the control loop (i.e., existing TCP is a link that the RTO forwards) Improve knowledge of the event state of both TCPs (blind as to whether due to data segment loss on top or corresponding ACK loss on the back link). Alternatively, the monitor software receives an ACK with a Seq No (replicated segment). . . The ACKing the ACKs can be executed through the above.

  With monitor software at both ends, the receiver can adjust to pass one-way transmission time to each other in both directions. The receiver-based monitoring software can derive the OWD (one-way delay) of the external Internet node from the time stamp option requested in the SYNC connection establishment. Sender-based monitoring software can be used for IPMP, NTP., Etc. during receiver-to-sender OWD via a time stamp option. . . Can be used to estimate the OWD to the remote receiver. If both ends have cooperating monitor software, OWD in both directions can be estimated → together with ACKs ACKing loop, this is due to packet drop in the transmission direction or ACK loss or physical transmission error in the return direction Enables packet loss to be distinguished.

  Owd is the time stamp to derive, or ipmp / icmp probe / ntp. . . . And so on. With the monitor software at both ends, when only the time stamp segment is received and when returning the Segment Seq No (the segment seq no transmission time in which all these two time stamp values are held in the event list) Combined with Seq No ACK arrival time, provides all OWD, end processing delay, etc.

  Known switch / router / end host processing latency under both known OWD directions, eg undersea cable, WAN link, and / or known timestamp drift / accuracy and / or congestion / non-congestion operating environment boundaries Should improve performance.

  ICMP for only packets with send, receive and return timestamps ready to give bi-directional OWD traverse the same path as tcp / udp in both directions with wan / lan / small internet subset. The RFC for tcp / udp must enable these timestamps. Periodic icmp probes can supplement passive tcp rtt measurements. IPMP provides a similar time stamp function, traverses the same path as the transmitted TCP segment, and uses the same IP address as the flow (s) TCP IP address, but a different port address Can be used as a probe packet to be transmitted using. When implementing both-end modified TCP / modified monitor software, the periodic probe packet has the same IP address as the flow (s) TCP IP address but a different port address. The modified TCP / monitor software at both ends, which can take the form of separate independent TCP connections or UDP connections or IPMP connections established between the modified TCP / modified monitor software at one end Can now include a time stamp when the segment with the Seq number first arrives and / or a segment with the same Seq number is ACKed and returned, allowing OWD measurement by both ends.

Implementation of TCP changes to work over the external Internet When either (or both) source senders or receivers are present in the external Internet, data packet communication between this source sender and receiver is, for example, external There is a possibility of receiving congestion packet drops that exceed our control, such as http web page download / ftp from internet sites. While the method (s) herein extend our modifications / invention to be applicable when either the source sender or receiver (or both) are present on the external Internet, It should be noted that similar to the various previously described methods included in this description, it is also applicable when both are in the Internet subset / WAN / LAN / Proprietary Internet.

The above effect of congestion packet drop should trigger RTO packet retransmission timeout and concomitant return to “slow start” with 1 segment size set to CWND in source sender TCP, and RTT / TCP congestion window size In order for the source sender TCP transmission rate per CWND to rise back to, for example, 1K * segment size, it should require an exponential increase of about 10 CWND from the initial “slow start” (2 ^ = 1 = 1K). ), I.e. the source sender needs to receive 10 consecutive uninterrupted ACKs (no congestion drop) from the receiver, which rises back to CWND of 1K * segment size at 200ms RTT It should take 10 * 300ms = 3 seconds to do A. If CWND reaches the SSThresh value, then CWND should now only increment linearly every RTT, not an exponential increment per ACK during “slow start”. RFC 2001 http: // www. faqs. org / rfcs / rfc2001. See html .

  The greatest degradation in end-to-end forwarding performance is the beginning of the accompanying re-entry to RTO packet retransmission timeout and “slow start” with one segment set in CWND upon congestion packet drop. Therefore, with remote source sender TCP. . . It would be advantageous to change the source sender TCP to react more quickly to generate their DUP ACKs to trigger fast retransmissions using.

  Using the DUP ACK fast retransmission / recovery algorithm that is commonly implemented in most current TCPs, Sender Source TCP can now be associated with a “slow start” only under the following two scenarios: It should only do an RTO packet retransmission timeout with incoming.

  (A) The sender source TCP sends the data packet (s) to the receiver (one single packet or a contiguous block of packets), all of which are lost / discarded and absolute Therefore, the receiver TCP has actually sent these packets to generate a DUP ACK for these unarrived next expected Seq number packet (s) There is no way to know whether or not. If any of the later packets of these transmitted consecutive blocks of packets actually arrives, then some of the earlier packets of these packets have been discarded. However, the receiver TCP should still be in a position to generate a DUP ACK to the sender source TCP to trigger fast retransmission / recovery, which instead only halves CWND, and therefore the sender source Note that the sender source TCP RTO packet retransmission timeout event is avoided, which causes TCP to re-enter "slow start" with a one-segment CWND. The existing RFC defines a default RTO timeout minimum minimum floor of 1 second under any circumstances, so a DUP ACK that triggers fast retransmission / recovery will be followed by a subsequent acknowledgment of these retransmitted packets, for example Note that if it arrives back to the sender source TCP within a minimum 1 second RTO timeout, it should prevent a pending normal RTO packet retransmission timeout event.

  (B) Acknowledgments generated by the receiver back to the sender source TCP are lost / discarded and therefore never arrive back to the sender source TCP, so the sender source TCP now times out the RTO, Re-enter “slow start” with CWND of one segment size.

  Scenario (A) above changes the sender source TCP so that, for example, the acknowledgment of the next data packet sent immediately after, for example, the acknowledgment of the data packet sent just before it was received back From 300 ms (or user input values, or algorithmically derived values that can be based on RTTest (min) and / or OTTest (min), etc., 300 ms is here referred to as 200 ms It was an example selected as being greater than the delayed acknowledgment maximum period) or for example 300 ms + the latest RTTest that has passed since the time of the transmission of the data packet transmitted immediately after this (ie we are Packet received is lost / discarded or its affirmation returns from sender to sender source TCP (It can be assumed quite safely that the answer has been lost / discarded) (if it is not received back later) (hereinafter referred to as algorithm A) (all transmitted data segments / data If all packets have already been returned and acknowledged (ie, most recently transmitted “maximum” valid SeqNo = latest received “maximum” valid ACKNo) That is, the sender TCP must now continue without being normally affected by the elapsed time interval event). The sender source TCP must now immediately enter the “continuous pause” state, but acknowledge The packet / normal data packet is then received back from the receiver TCP (so the round trip path is now complete) For example each 150 ms (or user input value or RTTest () that elapses during this “continuous pause” state until each packet is not discarded in either direction). min) and / or algorithmically derived values (which may be based on OTTest (min) ... etc.) and only one normal data packet and / or multiple pure ACK packet transmissions When an acknowledgment / normal data packet is next received back from the receiver TCP, the “continuous pause” stops immediately and the first 300 ms that triggered the “continuous pause” Can be prevented by returning to the same transmission rate / CWND size as before.

  The parts of Algorithm A can be adapted differently in various different combinations thereof.

  1. Rather than entering a “continuous pause” at the first 300 ms, the sender source TCP only reduces its CWND to x% (eg, 95%, 90%, 50%... User input or based on some devised algorithm).

And / or 2. Rather than entering a “continuous pause” at the first 300 ms, the sender source TCP does not change the CWND size, but “pauses” only during the “pause-interval”, and this pause-interval Can be input or derived from some devised algorithm (eg, a 100 ms pause-interval should be equivalent to reducing CWND to 90% in step 1 above) .

And / or
1. In addition to steps 1 and 2 above, when the first 300 ms elapses, instead of going into a “continuous pause”, it just instantly “pauses” only during the “initial pause-interval”. The interval can be user input or derived from some algorithm, eg, cumulative buffered packets built along router / switch nodes traversed by packets from sender source TCP to receiver TCP To ensure that all of the delay is cleared by this amount of, for example, 500 ms, it can be 500 ms to reduce the buffer latency experienced by subsequently transmitted packets.

And / or In addition to algorithm A or steps 1, 2, and 3 above, the packet transmission rate is for example 150 ms during “continuous pause” or “pause-interval” or “initial pause-interval” as in algorithm A If it is limited to one regular data packet and / or multiple pure ACK packets per elapsed period, the sender source TCP now instead is in a “continuous pause” or “pause-interval” or Transmit at a rate allowed by the new CWND size during the "Initial Pause-Interval", or send no packets at all.

And / or 5. In addition to algorithm A or steps 1, 2, 3, or 4 above, an acknowledgment packet is received next back from the receiver TCP (thus the round trip path is now not fully congested) That is, not discarding every packet in either direction (at this time the “continuous pause” or “pause-interval” or “initial pause-interval” immediately stopped and triggered the “continuous pause” In this case, the sender source TCP resumes the applicable transmission rate according to the limitation due to the new CWND size.

  Only one example of the above useful combinations is, for example, “initially paused” for 500 ms and does not transmit any packets during this eg 500 ms or one normal data packet and / or multiples during this eg 500 ms. Clearing the buffer delay by either allowing every ACK packet of e.g. every 150 ms, followed by no packet transmission during the "pause-interval" or this "pause-interval" of e.g. 100 ms Follow the “pause-interval” when e.g. 500 ms elapses, either by allowing one normal data packet and / or multiple pure ACK packets every 50 ms, and then the acknowledgment packet Immediately after being returned from the receiver TCP. The "Pause - Interval" stop, there should in the return to the new transmission rate is limited by the front same transmission and rate / CWND size or new CWND size initially elapsed example 300ms events. Note that a proper choice of the first derivation of eg 500 ms should help prevent other time critical packets such as VoIP / multimedia from experiencing severe buffer delays. The timestamp option can allow OTTest information to be utilized in sender source TCP decisions, and the SACK option should reduce the occurrence of DUP ACK events when used.

  The sender source TCP is further modified as described above, and packet loss is caused by congestion drop or physical transmission error. . . The requirement to re-enter “slow start” under all circumstances can be increased, ie TCP, now RTO “slow start” re-entry, fast re-transmission Half rate. . . Rather than RTO packet retransmission timeout or transmission rate / CWND up to, for example, 90% of the transmission rate / CWND before DUP ACK fast retransmission (or 100 ms equivalent "pause-interval" without changing CWND) Can be maintained. This should be applicable to any of the methods / subcomponent methods described in this description. Here, the further modified TCP will include an “initial pause-interval” to clear the cumulative buffered delay of the minimum RTO default lowest floor of the existing RFC, eg 1 second, etc. accordingly. It can react much more quickly to the congestion drop reaction.

  While the above algorithm A itself and / or various modified combinations thereof can be further modified / adapted, they should still be included in the principles disclosed therein. As one example among many, the change is not directly in the TCP stack itself, but changed monitor software / modified proxy TCP / modified IP forwarder. . . Modified monitor software / modified proxy TCP / modified IP forwarder. . . Keeps a copy of the data segment / data packet transmitted for the current window, eg changed monitor software / changes that the specific data segment / data packet sent was not ACKed back Proxy TCP / Modified IP forwarder. . . Perform an actual 3DUP ACK fast retransmission and an actual RTO packet retransmission (not just a TCP that should never do a fast retransmission and an RTO retransmission anyway) RPO timeout to “spoof” a specific acknowledgment of that particular “soon rate” data segment / data packet, where the actual data segment / data packet retransmission is performed, And when receiving fast retransmit DUP ACKs, they are not forwarded to TCP, but instead perform fast retransmit here (thus this modified end TCP does not have its CWND / transmission rate at all) Without change, this CWND / transmission rate can remain at the maximum TCP window size transmission rate. That is, "pause" period here, the actual effective transmission rate of the sender, i.e., by limiting the time slice available to the TCP transmission unrestricted within each second, it should be adjusted).

  Very often, the modified TCP is installed only on the user local host PC, and remote sender source TCP such as http web server / ftp server / multimedia streaming server has not yet implemented the modified TCP described above . Hence, the modified local host PC TCP should now act as a receiver-based modified TCP, i.e., remotely affect the remote sender source TCP. Some forms in which the local host TCP can affect remote sender source TCP congestion control / avoidance are to send a receiver window size update to the remote sender source TCP, a fast retransmission to prevent an RTO packet retransmission timeout at the remote sender source TCP. Send DUP ACK to remote sender source TCP for transmission / recovery. . . Etc.

  Here is an overview of a very simplified receiver-based modified TCP implemented in the monitor software (this can be further modified / adapted and directly the TCP itself rather than the monitor software) Can also be implemented).

  1. When receiving a TCP packet from a remote sender, be sure to check the source address and port if it already exists in the TCP table for each flow, otherwise use the various parameters for each new flow. Create a TCP TCB (it is not necessary to maintain the previous SEQ NO / send time table entry for all intercepted packets).

  . Latest packet received local system time (received from remote sender, pure ACK, or regular data packet), advertised window size of latest receiver packet (sent to remote sender by local MSTCP), latest receiver packet ACK number, the next expected Seq number expected from the remote sender (sent to the remote sender by local MSTCP and requires inspection of incoming and outgoing packets per flow, we now (It must be possible to immediately remove the TCP table entry for each flow during FIN / FIN ACK without waiting for inactivity). . . Such.

  (Optional) Upon completion of Sync / Sync ACK, immediately set, for example, 8K to CWND of the remote sender. This is preferably done via eg 15 immediate DUP ACKs with eg ACKNo = remote sender's initial SeqNo + 1, and the Divisional ACK is CWND by the number of bytes that some TCP was ACKed instead. May not work well, and the optimal ACK behavior may not be the same for all TCPs.

  Note: In the alternative, we wait for the first data packet received from the remote sender and then have an ACKNo set equal to the SeqNo just received from the remote sender (only one byte unnecessary Generate (for example, 15 DUP ACKs) or use a Divisional ACK (with retransmission expenses).

  TCP uses a 3-way handshaking procedure to set up a connection. The connection is set up by the initiator sending a segment with the SYN flag set and the proposed initial sequence number (seq = X) in the sequence number field. The remote then sets both the SYN and ACK flags, sets its sequence number field to its own assigned value in the reverse direction (seq = Y), and X + 1 acknowledgment field (ack = X + 1) Returns a segment with Upon receipt of this, the initiator stores Y, returns only a segment with the ACK flag set and a Y + 1 acknowledgment field.

2. If 300ms expires without receiving the next packet,
→ We generate the next expectation within 300ms from the last received packet in the software to generate three DUP ACKs with the next expected Seq No not arriving in the ACK number. Seq No is detected not to arrive, and at the same time it reports a 1800 byte window update within 3 DUP ACKs (equivalent to sender's “pause” + 1 packet), eg 100ms is a pure ACK or normal data packet It only needs to keep sending the same 3 DUP ACK window updates of 1800 bytes, incremented by 1800 bytes each time if it has not been received at all, but the ACK or normal data packet is actually the next ACK or normal data packet is then received again from the remote Until, repeatedly 100ms every previous to restore the window size (which is transmitted from the local MSTCP to remotely ACKNo field; to "recorded" latest "largest" set CKNo) normal (3 Send the same single window update ( not two DUP ACKs) and then repeat the above 300 ms expiration detection loop at the very beginning of step 2 above.

  Here, we can also send 3 DUP ACKs instead of a single window update packet, but after 2 additional 100 ms, a single window update ACK packet has a total of 3 DUP ACKs. It should be a window update packet and, of course, the alternative here is to replace any window update packet, eg DUP SeqNo window update packet. . . Note that, and so on.

  (This ensures that scenario A, which causes a slow start re-entry of the pending remote MSTCP RTO timeout, is avoided and that the pending RTO is replaced by a DUP ACK fast resend / recovery event. If there are actually no packets, it is not really a problem that we unnecessarily transmitted 3 DUP ACKs with ACK number = next expected Seq number.

Scenario B sends three identical DUP ACKs every 100 ms until the next ACK or data packet is received from the remote (ie, the bottleneck is not currently discarding all remotely transmitted packets). When the next ACK or data packet is received from the remote, managed by continuing to transmit, we send a single window size recovery packet every 100 ms until any next packet is received. Continue (ie, even if all window restoration packets are discarded in the worst case), after 300 ms, this process is repeated, again guaranteeing window “pause” and subsequent window restoration attempts.

  Note: We continuously increment the advertised receiver window size. This is because the remote may have used up the window size advertised by the previous available receiver, but the transmitted packet (s) were discarded and never reached the receiver. It is. By making sure that the remote has never re-entered CWND = 1 due to slow start, usually RTO, we achieved a very large web page download time reduction. Note that fast retransmission does not cause a slow start, and three DUP ACKs only halve the remote existing CWND.

The above algorithm can be further simplified without the need to send a receiver window size update to “pause” the TCP at the other end as follows:

  1. When receiving a TCP packet from a remote sender, be sure to check the source address and port if they are already in the TCP table for each flow, otherwise use the various parameters to check the TCP for each new flow. Create TCB (no need to maintain previous SEQ NO / send time table entry for all intercepted packets).

  . Latest packet received local system time (received from remote sender, pure ACK, or normal data packet), ACK number of latest receiver packet, ie next expected Seq number expected from remote sender (remote by local MSTCP Sending to the sender and requiring inspection of incoming and outgoing packets per flow, we now have the per-flow TCP table entries immediately upon FIN / FIN ACK without waiting for the normal 120 second inactivity Must be able to be removed). . . Such.

  (Optional) Upon completion of Sync / Sync ACK, immediately set, for example, 8K to CWND of the remote sender. This is preferably done via, for example, 15 immediate DUP ACKs with ACKNo = remote sender's initial sequence number + 1, and some TCP instead increments CWND by the number of bytes ACKed instead. As such, Divisional ACK may not work well and the optimal ACK behavior may not be the same for all TCPs.

  Note: In the alternative, we wait for the first data packet received from the remote sender and then have an ACKNo set equal to the sequence number just received from the remote sender (only one byte unnecessary) For example, generate 15 DUP ACKs or use a Divisional ACK (with a small retransmission fee).

  TCP uses a 3-way handshaking procedure to set up a connection. The connection is set up by the initiator sending a segment with the SYN flag set and the proposed initial sequence number (seq = X) in the sequence number field. The remote then sets both the SYN and ACK flags, sets its sequence number field to its own assigned value in the reverse direction (seq = Y), and X + 1 acknowledgment field (ack = X + 1) Returns a segment with Upon receipt of this, the initiator stores Y, returns only a segment with the ACK flag set and a Y + 1 acknowledgment field.

2. If 300ms expires without receiving the next packet,
→ We generate the next expectation within 300 ms from the last received packet in the software to generate three DUP ACKs with the next expected Seq set to ACK No. It is only necessary to detect that the Seq No to be received does not arrive.

  For example, if 100 ms passes without receiving a pure ACK or normal data packet at all, it will continue to send the same three DUP ACKs, but if the ACK or normal data packet is actually received next The above-described 300 ms expiration detection loop is repeated at the very beginning of step 2 above.

  (This ensures that scenario A, which causes a slow start re-entry of the pending remote MSTCP RTO timeout, is avoided and that the pending RTO is replaced by a DUP ACK fast resend / recovery event. If there are actually no packets, it is not really a problem that we unnecessarily transmitted 3 DUP ACKs with ACK number = next expected Seq number.

Scenario B receives three identical DUP ACKs every 100 ms until the next ACK or data packet is received from the remote (ie, the bottleneck is not currently discarding all remotely transmitted packets). Managed by continuing to transmit: When the next ACK or data packet is received from the remote, we send a single window size recovery packet every 100 ms until any next packet is received (Ie, even if all window restoration packets are discarded in the worst case), after 300 ms, this process is repeated, again guaranteeing window “pause” and subsequent window restoration attempts).

The above highly simplified algorithm is derived from various other similar algorithms herein:
1. The purpose of receiver-based is to make remote sender source TCP that has not made this change behave as much as a “mirror image” sender-based as much as possible (but receiver-based, for example, sender source TCP is unarrived) (There are some minor differences that require workarounds, such as ... if the next expected SeqNo data segment has already been transmitted). The sender-based “pauses” when the ACK of a normal data packet is delayed, but the MSTCP timeout retransmission (Seq No = <pause-per-interval when detected by the last sent Seq No recorded Allows one regular data packet to be forwarded as a probe and then “spoofs” the ACK to MSTCP for interval ACKTimeout to return CWND to the previous level prior to RTO. For later enhancements, we first get a simplified barebone upgrade.

  2. The normal data packet probing method using the Seq No / transmission time main event list and the retransmission event list is simple enough. It is necessary to guarantee the Timestamp option negotiated during the SYNC / SYNC ACK by changing the intercepted SYNC / SYNC ACK packet and / or PC registry settings.

  3. When arriving OTTest> current recorded OTTest (min) +300 ms, this signals the congestion buffer delay (OTTest (min) is our latest best estimate of non-congested OTT from the remote sender to us Value) → send a 1800 byte window update to allow one regular 1500 byte Ethernet packet to be received, and also send multiple small pure ACKs.

  4). Arriving OTTest> current recorded OTTest (min) + same window update of 1800 bytes incremented by 1800 bytes if OTTest (min) elapses without receiving a normal data packet or a pure ACK at 300 ms (Thus, for every OTTest (min) that has passed, the remote can forward a single new regular data packet as a probe). At any point, if the incoming on-time OTTest = <current recorded OTTest (min) +300 ms, it immediately sends a window update that restores the previous receiver window size, i.e., the remote now Resume normal transmission rate of.

  (Note: This tries to prevent packet drops by throttling the rate, so the remote never has to slow start again, but being an external internet actually works well For this reason, paragraph 4 above must be replaced by paragraph 4 below, which is now simple to restore the remote transmission rate as soon as possible in the event of a packet loss event. If we can retransmit the remote transmission rate instantly similar to sender-based “spoofing” when we detect a retransmitted packet, is packet drop causing a remote slow start? I do n’t care about that anymore).

  4). A remote sender packet “pending” retransmission is detected whenever 300 ms elapses without arriving Seq No> next expected Seq No and missing gap Seq No (s). (I.e. it can now safely be assumed that the gap packet has been lost and the remote sender should now have retransmitted with a slow start pending with the expiration of the RFC 1 second minimum ceiling. → However, our MSTCP should already generate three DUP ACKs on its own upon receipt of three out-of-order Seq No packets that will cause the remote to retransmit fast without entering slow start again (remote The sender simply happens to have only two out-of-order Seq No. If not, this should not confuse things, because we can simply allow the remote to slow start because the remote is not trying to send much at this time. → We generate the next expected Seq No within 300ms from the previously received packet in order to generate three DUP ACKs with the expected Seq No set to ACK No. It only needs to detect that it does not arrive.

(SACK may be useful to reduce the occurrence of DUP ACK, and Divisional ACK, DUP ACK, and Optimistic ACK are useful to restore remote transmission rate similar to sender-based “ACK spoofing”. Note that there is a possibility : http://www-2.cs.cmu.edu/~kgao/course/network.pdf , http://www-2.cs.cmu.edu/~kgao /Course/network.pdf and Google Search terminology “Ack spoofing”).

  Here, the (sample-only) algorithm of the receiver-based method is attached.

1. 1. Only monitor TCP flows from subnet user input, to specified subnet TCP flows with external sources / destinations are monitored differently 2.1 External sources (ie customized TCP acts as a receiver-based flow controller).

  . Select the Timestamp option for these flows during connection establishment (Can the Sync packet be modified? Alternatively, all the flows in paragraphs 1 and 2 above can also be run through the PC registry to group together using time stamps. May need to be set? Windows server 2003 only allows the timestamp option when initiated by remote TCP !?).

  . Check this TCP incoming packet for remote sender TSVal and record this as OTTTest (max) and OTTest (min) of the very first packet received (current receiver system time-TSVal). OTTest represents one way trip time estimate, ie the maximum and minimum OTTs observed so far. OTTest (max) and OTTest (min) are updated from all subsequent packets received.

  . If OTTest-OTTest (min) of incoming packet> eg 100 ms (user input parameter), the remote sender must “pause” and the customized TCP will be the last sequence sent at the receiver Number or last received ACK No-1 set to Seq No (thus, if the receiver does not send the data segment to the remote sender with the ball, there is no Seq No sent at the end of the receiver), eg Generate a 50 byte 1 byte garbage (or no data) segment window size advertisement packet (not necessarily 0 to allow remote sender TCP to respond / pure ACK).

  The receiver sends the same generated window advertisement packet (however, the Seq No or the last received ACK No-1 may have been modified) to these “replicated packet window update” packets. There is an acknowledgment received for one of them, so at least one of these window update packets has been received at the sender and that acknowledgment has arrived now (lost in either direction) It will continue to transmit until indicated (possibly) and its OTTest-OTTest (min) should be <eg 100 ms (we will not stop the “pause” until there is no congestion).

  The “pause” can also be stopped on any other packet that arrives within OTTest (min) +100 ms, for example a normal data packet. In that case, the receiver sends a window update packet that is identical but has the window size field set to the previous value of its “pause” (this value is recorded before, for example, providing a 50 byte advertisement). The

2.2 Remote destination (ie customized TCP acts as sender-based)
. The timestamp option is not necessary, but is useful to know the one-way delay back to better determine the cause of RTT <timeout (which can be caused by reverse path congestion).

  . When TCP (s) originated by MSTCP with Seq No <last sent Seq No is sent (packet drop retransmission), MSTCP should enter slow start again: customized TCP Will now spoof an “ACK” back to MSTCP for all packets originating from MSTCP, eg, for a period of 100 ms. This should return the congestion window to eg the TCP window size. All subsequent forwarded buffered packet drops can be fast retransmitted via the receiver's three DUP ACKs (in that case, the customized TCP will also return an ACK). Can be spoofed).

Our algorithm:
1. When receiving a TCP packet, be sure to check the source address and port if they are already in the TCP table for each flow, otherwise create a new TCP TCB for each flow using various parameters. (There is no need to maintain a previous Seq No / Send Time Table entry for all intercepted packets).

  . Latest packet received local system time (pure ACK or normal data packet), advertised window size of latest receiver packet, ACK number of latest receiver packet, ie next expected Seq number (incoming packets per flow) And we must now be able to immediately remove per-flow TCP table entries during FIN / FIN ACK without waiting for 120 seconds).

2. If 300ms expires without receiving the next packet,
→ We generate the next expectation within 300ms from the last received packet in the software to generate three DUP ACKs with the next expected Seq No set to ACK No. It is only necessary to detect that the Seq No received does not arrive and at the same time convey a 1800 byte window update within 3 DUP ACKs (equivalent to the sender's “pause” +1 packet): Expects three DUP ACKs to be back ACKed again by the remote, for example, the same three 1800 bytes incremented by 1800 bytes each time 100 ms elapses without receiving a return ACK DUP ACK window update must continue to be sent, but return ACK or normal data packet If the received (regardless of OTT time), and transmits the previous restoring the window size three DUP ACK window update.

  (This ensures that scenario A, which causes a slow start re-entry of the pending remote MSTCP RTO timeout, is avoided and that the pending RTO is replaced by a DUP ACK fast resend / recovery event. If there are actually no packets, it is not really a problem that we unnecessarily transmitted 3 DUP ACKs with ACK number = next expected Seq number.

  Scenario B is the same until “ACKing the ACK” is received or until the next regular data packet is received (ie, the bottleneck is not currently discarding all remotely transmitted packets) Is managed by continuing to send 3 DUP ACKs every 100 ms: when an “ACKing the ACK” or the next regular data packet is received from the remote, we receive an “ACKing the ACK” Until then, it continues to send three DUP ACKs to restore the advertised window size every 100 ms.

  As an alternative to sending three DUP ACKs for the next expected Seq No segment, we set the next expected Seq No-1 in the ACK No field of the three DUP ACKs instead. Can be done (at the expense of only one extra byte being retransmitted), in which case we will rotate the next expected Seq No-100, -99, -98. . . . There is clearly a need to set the Seq No field using -1.

However, http: // www. cs. ruggers. edu / ~ muthu / wtcp. Want to see pdf , at this site, it is suggested that TCP retransmit in this case "starting with the lowest unacknowledged packet or the first unsent packet within the current congestion window" Yes.

  We want to expect this to be closer to the specification, and the software will still remain "passive passthrough" without changing either the received packet or the transmitted packet. Remote MSTCP now never RTO re-entry slow start.

  For single PC shareware, we don't need any probe and time stamp function (paragraph 2): window updates until every 100 ms until a pure ACK or regular data packet is received (reception time is not a problem) Can be simply repeated (instead of 3 * OTTest (min) in paragraph 4). Here, when our flow discards the packet, we see that the MSTCP of the other flows that traverse the same bottleneck that the packet is discarded will RTO rate around the same time as our own MSTCP. Know → We can safely restore the remote sender's CWND.

  1. The goal is to make the remote behave as much as possible as a "mirror image" sender-based: sender-based "pauses" when the ACK of a regular data packet is delayed, but MSTCP resends the timeout (Seq No = <Allows one regular data packet per pause-interval to be forwarded as a probe when detected by the last recorded Seq No recorded, then CWND is To “spoof” the ACK to MSTCP during the ACK Timeout interval to return to the previous level, we can now enhance later (eg, SACK gap packet functionality may be useful) First, a simplified mirrored bear bow Receiver-based version upgrade must be obtained.

  2. The normal data packet probing method using the Seq No / Send Time Main Event List and the Retransmit Event List is simple enough. It is necessary to guarantee the Timestamp option negotiated during the SYNC / SYNC ACK by changing the intercepted SYNC / SYNC ACK packet and / or PC registry settings.

[No longer needed with simplified algorithm. When arriving OTTest> current recorded OTTest (min) +300 ms, this signals the congestion buffer delay (OTTest (min) is our latest best estimate of non-congested OTT from the remote sender to us Value) → send a 1800 byte window update to allow one regular 1500 byte Ethernet packet to be received, and also send multiple small pure ACKs. ].

[No longer needed with simplified algorithm. Arriving OTTest> current recorded OTTest (min) + same window update of 1800 bytes incremented by 1800 bytes if OTTest (min) elapses without receiving a normal data packet or a pure ACK at 300 ms (Thus, for every OTTest (min) that has passed, the remote can forward a single new regular data packet as a probe). At any point, if the on-time OTTest arriving = <current recorded OTTest (min) +300 ms, it immediately sends a window update that restores the previous receiver window size, ie, the remote now Resume normal transmission rate. ].

  (Note: This tries to prevent packet drops by throttling the rate, so the remote never has to slow start again, but being an external internet actually works well It is very difficult to know the OTTest just before the packet drop, so the above paragraph 4 must be replaced by the lower paragraph 4, and the lower paragraph 4 is now the packet loss event Simply concentrate on restoring the remote transmission rate as soon as possible, that is, we can instantly restore the remote transmission rate, similar to sender-based "spoofing" when detecting a retransmitted packet If the packet drop causes a slow start remotely I do not care).

  4). The remote sender packet “pending” retransmission is always sent by the software when 300 ms elapses without arriving Seq No> next expected Seq No and missing gap Seq No (s). Detected (ie, it can now be safely assumed that the gap packet has been lost and the remote sender should now finish retransmitting with a slow start pending at the expiration of the RFC 1 second minimum ceiling. → But our MSTCP already generates three DUP ACKs on its own upon receipt of three out-of-order Seq No packets that let the remote re-enter slow start / reenter fast (The remote sender simply happens to send two out-of-order Seq This shouldn't confuse things if you only have No and nothing else, because the remote is not going to send much at this time, we simply throw the remote → we generate the next expected Seq to generate three DUP ACKs with the next expected Seq No not arriving at the ACK No. Communicate 1800 byte window update in 3 DUP ACKs (equivalent to sender's “pause” + 1 packet) at the same time detecting in software that No arrives within 300ms from last received packet Only we need: here we have 3 DUP ACKs also back ACKed by the remote For example, if 3 * OTTest (min) elapses without receiving a return ACK, the same three DUP ACK window updates of 1800 bytes incremented by 1800 bytes each time must continue to be transmitted. Otherwise, if a return ACK or normal data packet is received next (regardless of OTT time), it will send three DUP ACK window updates to restore the previous window size.

  (Here, we only detect packet drops early to update the receiver window size, which is equivalent to a sender-based “pause” +1 packet).

5. The actual DUP ACK that causes the remote to retransmit fast is all handled by MSTCP itself. The software detects two additional DUP ACKs for intercepted MSTCP (a total of three if they were previously normally acknowledged), and then a Divisional ACK / DUP ACK / Optimistic ACK All that is required is to restore the remote CWND immediately via the technique. http: // artechnica. com / reviews / 2q00 / networking / networking-3. html and http: // www. useix. see org / events / usits99 / summarys / .

(Here we are doing something similar to a sender-based “spoof” ACK when MSTCP sends two additional DUP ACKs)
Note: Scenario B is until “ACKing the ACK” is received or the next regular data packet is received (ie, the bottleneck is not currently discarding all remotely transmitted packets) Taken care of by continuing to send the same three DUP ACKs every 100ms until: "ACKing the ACK" or the next normal data packet is received from the remote, we receive "ACKing the ACK" Until it is done, it will continue to send 3 DUP ACKs every 100ms to restore the advertised window size.

In the following cases:
MSTCP always acknowledges all out-of-order ACKs (ie, ACKs that acknowledge segments that have not yet been transmitted), otherwise all ACK No fields are set to the same expected Seq number. If so, it should be necessary to include the Seq No field of 3 DUP ACKs (Note: DUP Seq Number packets are always ACKed by RFC !?).

  We have 100 previous Seq Number fields in the DUP ACK with all ACK No fields set to the same expected next Seq number (ie, the “recorded” next expected ACK-100 ) May be used in a rotary manner, so that the DUP ACK is now in the next expected Seq No-100 recorded in a different Seq No field, respectively. Either is set (no two DUP ACKs have the same Seq number).

  Note: 3 DUP ACKs for untransmitted segments do not necessarily trigger CWND halving by remote MSTCP and do not set SSTHRESH to half of current CWND (packet has been sent but discarded) (In this case, CWND is certainly halved and high-speed retransmission is performed) or has not been transmitted yet (in this case, CWND is halved and high-speed retransmission is not performed. It may be either) or there may be a slight unnecessary performance impairment.

Method of using inter-packet-arrival delay as a congestion indication In any of the methods and subcomponent methods previously described in this body description, the congestion indication or packet drop indication is changed instead. Modified TCP / modified monitor software / modified proxy / modified port forwarder. . . The delay between packet arrivals, eg, specifically, the “elapsed tine interval” between consecutive packets directly, is the last packet received from the remote source TCP or remote receiver TCP (pure net May be based on some user input interval (or RTTest, OTTest, RTTest (min), OTTest (min),...) After the ACK or normal data packet, etc. Can be detected / inferred by observing times exceeding (derived from the algorithm). Here, it should be noted that the TCP connections are symmetrical between each end that can be transmitted and received at the same time. The data segment / data packet transmitted by one end and the return response ACK from the other end corresponding thereto (hereinafter referred to as subflow A) Can be mixed with the data segment / data packet that the other end independently transmitted and the return response ACK (hereinafter referred to as subflow B) from their independent corresponding other end: TCP / modified monitor software / modified proxy / modified port forwarder. . . Etc., when observing the delay between the above packet arrivals, it must “distinguish” between the packet arrivals of subflow A and / or subflow B completely independently, and observe them separately. Independently along the return path, when A's transmitted data segment / data packet is discarded along the forward path to the other end, so that no corresponding return response ACK is returned from the other end along the return path. The other end, ie, subflow B's transmitted data segment / data packet (if any) arrives at this end incorrectly assuming that the independent subflow A's “elapsed time interval” has not yet expired. I will not let you. Modified TCP / modified monitor software / modified proxy / modified port forwarder at one end. . . Etc., when acting as a sender, only observe the corresponding return response ACK of its own subflow A for the inter-packet delay for the “elapsed time interval” expiration and ignore the transmission segment / packet of the independent subflow at the other end It should be. Modified TCP / modified monitor software / modified proxy / modified port forwarder at one end. . . Only observe the incoming segment / packet of the other end's own subflow B for the inter-packet delay for the expiration of the “elapsed time interval” when acting as a receiver, and this end's own independent subflow A (exists) In case) ignore the corresponding arriving returned response ACK stream. This task must be simple enough: one end, when acting as a sender-based, monitors the corresponding incoming return response ACK of its own transmitted packet for "interpacket interval" delay for "elapsed time interval" expiration Only when it acts as a receiver-based, it should only need to monitor the transmitted data segment / data packet at the other end: In addition, its “interpacket interval” delay is now “elapsed time” If the transmission packet of the independent subflow at the other end continues to arrive before the expiration of the "elapsed time interval" of the corresponding return response ACK of the transmission packet of the independent subflow at this end from the other end at which the "interval" expires This can be done from the other end to react accordingly. And that the one-way path to the end is "UP", should one-way path from the end to the other end to provide a solid display / definite inference of additional and it is a "DOWN". For example, RTTest or OTTest or RTTest (min) or OTTest (min). . . The benefit of allowing much faster rate response times by being able to specify "elapsed time intervals" much smaller than, etc., and to detect / infer congestion and / or packet drop events and / or physical transmission error events (Even even non-congested RTT, OTT, etc. can be hundreds of milliseconds on the Internet and cannot be confirmed, or its maximum limit cannot be confirmed in advance, but the above from the last reception of the packet The elapsed time interval can be selected to be as small as 50 ms, for example, instead of a few hundred milliseconds).

  For example, during ftp / httpt website downloads, regular data packets are continuously transmitted when RTO packet retransmissions are not interrupted by re-entering slow start with CWND reset to 1 or segment size. Assuming that the lowest bandwidth link of the path traversed by the packet in this case is the lowest bandwidth link of the source TCP's first mile to send, eg 500 Kbs DSL, the DSL transmission medium from the source sending a single packet The transmission time delay to fully exit should not be a significant factor in this case, and is small, for example 24 ms for packets with a large 1500 byte Ethernet size (1500 * 8 / 500,000 = 24 ms). On the other hand, for the last mile 56 Kbs modem dialup, the transmission delay time of a normal 500 byte packet should be about 71 ms (500 * 8/56000 = 71 ms). In today's Internet, the lowest possible bandwidth link along the path traversed by a packet should be 56 Kbs in the worst case scenario. The default packet size is typically around 500 bytes, as negotiated by TCP during connection establishment. The “inter-packet arrival” method (and / or the “synchronized” packet method, see later sections) is based on the assumption of the 56 kbps minimum bandwidth link along this path and the maximum packet size negotiated. Start with the "time interval" value setting and the "synchronization" interval value setting, and then the actual interval between received packet arrivals during normal data packets (or during ACK for actually transmitted data packets) You can continue to monitor the latest observed minimum value and dynamically adjust the “Elapsed Time Interval” value setting and the “Synchronization” interval value setting, for example, the latest minimum “inter-packet arrival” interval If the current value is only 20 ms, the “Elapsed time interval” value will be displayed. Is, for example, 80ms can be set, to "synchronize" interval value now can be set, for example, 40ms. . . Or can be derived based on an devised algorithm. The interpacket spacing when data packets are continuously sent from the sending source TCP and received at the receiver TCP, even if the traversed link introduces various delays and / or buffer delays, respectively. Same packet arrival interval as above, centered around 24 ms or 71 ms, and cut-through switching that should represent the single packet transmission time delay that each node encounters compared to store-and-forward switching (store-and-forward) The total amount of intervals due to the single packet transmission time delay encountered at each node along the path traversed. This is because it does not immediately add an extra, for example, 200 ms from the previous packet very suddenly to the next packet of course followed by a buffer delay (ie, the additional buffer delay is continuous to each successive packet). Packets are not dropped / lost along the route (if so, this is “infinite” from the previous transmitted packet to this subsequent packet) Assuming additional delay and this subsequent packet may be discarded / lost), it will affect the data packets uniformly, and these data packets will be separated around the 24ms or 71ms above respectively. Because we arrive at the receiver (we will not receive this congestion event and / or packet loss event and / or physical transmission error event If the inter-packet delay is suddenly above a certain value, eg 100 ms, ie 100 ms since the last packet was received, ie a packet with 100 ms followed directly, ie a packet with the correct next expected sequence number. Can be detected / infered by observing that it has passed without receiving: but if other subsequent subsequent packets can be received within this 100ms, and this particular directly following packet is not received Even so, we will treat this as a “gap” congestion event and / or a packet drop event and / or a physical transmission error event, and handle it in a similar or slightly different manner, if desired. Is possible).

  At each node along the path traversed when the node uses store-and-forward switching (rather than cut-through switching that should represent a single packet transmission time delay encountered at each node compared to store-and-forward) The total amount of interval due to the single packet transmission time delay encountered is when the nodes along the traversed path are high bandwidth capacity links (when store-and-forward switching is used instead of cut-through switching). 2) to a few tens or two to three hundred milliseconds when the traversed link has a low bandwidth capacity. For example, for 500 Kbs first mile, 10 Mbs next link, 100 Mbs next link, 10 Mbs next link, and 500 Kbs DSL last receiver last mile link, here the congestion buffer delay at each traversed node is The total transmission completion time delay that a single 1500 byte size packet encounters at each successive stage of a forwarding link with nodes that all perform store-and-forward switching compared to cut-through switching that is assumed to be none is It should be approximately 24 ms + 1.2 ms + 0.12 ms + 1.2 ms + 24 ms = 50.52 ms, ie when finally received at the destination, the inter-packet arrival interval is directly between successive packets. It should be centered around 0.52ms. On the other hand, for 56Kbs first mile modem link, 10Mbs next link, 100Mbs next link, 10Mbs next link, and finally 56Kbs receiver last mile modem link, here the congestion buffer delay at each of the traversed nodes The total transmission completion time delay that a single 500 byte size packet encounters at each successive stage of the forwarding link with nodes that all perform store-and-forward switching compared to cut-through switching that is assumed to be none is It should be about 71 ms + 0.4 ms + 0.04 ms + 0.4 ms + 71 ms = 142.84 ms, i.e., when finally received at the destination, the inter-packet arrival interval is directly between successive packets. It should be centered around 0.52ms. Increase the time at which the packet finally arrives from the source to the destination, for example a few seconds or more, rather than the next packet sent directly after (i.e., the referenced previous packet sent earlier) Any congestion buffer delay that may cause a much longer time to arrive at the destination receiver (for example, 300 ms longer than the earlier referenced transmitted packet) is Caused by the cumulative congestion buffer delay encountered at the node that is encountered, but between any two directly consecutive next transmitted packets and the immediately preceding transmitted packet as compared to the immediately preceding transmitted packet The “extra” increased cumulative congestion buffer delay that Not, i.e. it may be much smaller than the above, eg 300ms, between two separate transmitted packets that span several seconds apart (assuming that the congestion level is increasing here, The same reasoning applies as well when congestion levels are decreasing). This “extra” additional congestion buffer delay should be as small as between the next packet that immediately follows and the packet that immediately precedes it, and it is optional between the next packet that immediately follows and its immediately preceding counterpart. It should only increase gradually between subsequent pairs of. This possible extra small amount of congestion buffer delay between any subsequent pair of the next packet that immediately follows and its immediately preceding counterpart is transmitted after the congestion level is stable / directly adjacent. Small, even if neutralized evenly between other subsequent pairs of the same pair, but detects / congests and / or packet drop events and / or physical transmission error events. To infer, it must / can be taken into account when selecting / deriving an elapsed time period value when the next / directly next packet is not received from the sender source TCP. However, in very rare cases, the congestion level can be, for example, 100 Mbps for incoming links and only 10 Mbps for outgoing links. . . For example, a buffer delay of, for example, 200 ms can be built up suddenly within a short period of time, eg, 100 ms (not impossible), in which case we can now conveniently refer to congestion events and / or Or, in addition to packet drop events and / or physical transmission error events, scenarios that consider elapsed time intervals can be included to detect / infer this very rare and very abrupt congestion buffer delay event. This sudden very rare congestion level increase is now no longer a sudden congestion, as between any subsequent subsequent transmitted pairs of the next packet directly following and its immediately preceding counterpart. When the increase stabilizes and is evenly smoothed between other subsequent further transmitted pairs after a pair that is transmitted immediately adjacent, it is evenly neutralized to the “elapsed time interval” to expire. Note that you shouldn't.

  Note that the TCP connection is full-duplex, i.e., both ends of the connection can simultaneously transmit and receive as sender source TCP and receiver TCP. For example, ftp file download / http web page download. . . Even if only one end of the connection is doing almost all or all of the transmission of normal data packets, the receiving end TCP always responds to received normal data packets, It should have sent an acknowledgment back towards the end TCP that is doing almost all or all of the normal data packet transmission. For this reason, the “Elapsed Time Interval” method outlined in the previous paragraph above is that the “Elapsed Time Interval” is a pure ACK packet and / or a piggyback ACK packet from the TCP at the other end receiving the download. When expiring without receiving, the end TCP, which is doing almost all or all of the normal data packet transmissions, now has congestion events and / or packet drop events and / or physical transmission error events and / or “ Similar to end-of-the-edge TCP doing almost all or all of normal data packet transmission in that it can infer the detection of very rare and “very sudden” congestion level increase events and react accordingly Applies to However, in this case, the receiver end TCP performs a Delayed Acknowledgment (an ACK that is generated when every other packet or 200 ms expires first), and this Delayed ACK option is set to a specific Considered to include a possible additional 200 ms delay introduced by the Delayed ACK mechanism in the setting of an “elapsed time interval” value that is selected or algorithmically derived when activated for a per-flow TCP connection For example, in the case of Delayed ACK, the “Elapsed Time Interval” must be added with 200 ms, or, optionally, 200 ms is added to the “Elapsed Time Interval” No, instead, a 200ms delay events of this met worst case, included among the various events to be inferred that can be / detection at the time of expiration "elapsed time interval". This event is rare and should occur, for example, when there is a stagnation of the sender-source TCP transmission of the packet to the receiver end TCP, and thus has a significant impact on throughput performance due to the worst case Delayed ACK scenario. Should not.

  Upon detection / inference of the above event when the “Elapsed Time Interval” expires without receiving the next packet (where we do not require any information and optionally RTT, OTT. Etc. and no RTO calculation based on historical RTT values (instead of the actual packet retransmission timeout, e.g. some user input value or e.g. historical packet arrival interval value ...). Can optionally be triggered based on a value derived from an algorithm based on, etc.), optionally, such a requirement can now be removed from the modified TCP because it is now a redundant remainder to the requirement Note) modified TCP / modified software monitor / modified proxy / modified IP Over da / modified firewall. . . Etc., as described in the previous method / subcomponent method in this description, are modified without existing combined actual packet retransmissions and / or actual packet retransmissions at the same time as CWND reduction / rate reduction. Various modified “pause” methods with or without separate CWND reduction / rate reduction and / or concomitant CWND reduction / rate reduction. . . And so on. If the above process was triggered when the "Elapsed Time Interval" of the "Interpacket Interval" delay expired, then on the next arriving packet from the same subflow from the sending source TCP, The triggered process can be terminated either immediately or after some defined interval as an option, and the CWND size / rate limit is set to the previous value before the “elapsed time interval” expires. And / or optionally “unpause” the ongoing “pause”. . . And so on. The arrival of this packet now indicates that the path from the sender source TCP to the receiver TCP is not currently full congestion that throws away all packets: As an option, we also have normal data correct If it must be the very next expected packet with the next expected sequence number, and / or a pure ACK packet is received last from its Sequence Number field = sender TCP to receiver TCP This incoming packet can be requested if it has to have a valid sequence number (or the latest maximum valid acknowledgment number -1 sent from the receiver TCP to the sender source TCP).

Similarly, modified TCP / modified software monitor / modified proxy / modified IP forwarder / modified firewall. . . Etc. as an option and / or in addition, as described in the previous method / subcomponent method of the description of this body, the existing combined actual packet retransmission at the same time as the CWND reduction / rate reduction, and / or the actual Modified isolated CWND reduction / rate reduction with or without accompanying packet retransmission and / or various modified “pause” methods with or without accompanying CWND reduction / rate reduction. . . Or the like can be executed by the TCP at the other end. Alternatively, modified TCP / modified software monitor / modified proxy / modified IP forwarder / modified firewall. . . Etc. as an option and / or afterwards, as described in the previous method / subcomponent method in this description, and the existing combined actual packet retransmission simultaneously with CWND reduction / rate reduction, and / or actual Modified isolated CWND reduction / rate reduction with or without accompanying packet retransmission and / or various modified “pause” methods with or without accompanying CWND reduction / rate reduction. . . To the other end TCP (without doing it at all to the local TCP !. Such a function can be used, for example, if the other end TCP performs almost all or all of the normal data packet transmission. It should only be possible to go to (which should be useful when it is an unmodified standard TCP). If the above process is triggered when the “Elapsed Time Interval” expires, the triggered process is either immediately or upon arrival packets arriving from the same subflow from the other end TCP. Can optionally end either after a defined interval, the CWND size / rate limit can optionally be restored to its previous value before the “elapsed time interval” expires, And / or optionally “unpause” the ongoing “pause”. . . And so on. Remote TCP / remote application / remote process on the other end TCP if the other end TCP is an existing unchanged TCP or has not yet been modified to allow such a mechanism For this reason, it is not easy to change the internal CWND size / transmission rate of the TCP at the other end directly via a certain protocol command. However, even if the TCP at the other end is an existing unmodified TCP or has not yet been specifically modified to allow such a mechanism, As outlined in the various previous methods / subcomponent methods of the description, the “pause” and / or “unpause” and / or “pause” defined maximum number of bytes / packets Enable transmission. . . Can be easily implemented, for example, “0” bytes and / or “1600 bytes” to cause various “pauses” in the TCP at the other end. . . Send receiver window size update packet, etc., send receiver window size update packet of previous size before “triggered” event to “unpause” TCP at other end / restore its normal operation. . . (See also the previous section on implementing TCP changes to work over the external Internet ).

  Independently and / or optionally, in addition to the various methods described above, such as the “Elapsed Time Interval” method, existing or previously described TCP / Monitor Software / TCP Proxy / IP Forwarder / Firewall. . . And so on, each modified end of the TCP connection automatically generates a “synchronized” data packet to the other modified end (or simply a TCP connection) One modified end of the network automatically generates a "synchronized" data packet to the other unmodified or modified end), eg, a single packet of the same subflow Is not sent towards the other end of the TCP, and whenever the “synchronization” interval expires, generate a “synchronize” packet and send it to the other end of the TCP, so that at least all It is guaranteed that there will always be one packet sent towards the modified TCP at the other end during the “synchronize” interval period (eg, “elapsed time interval” half of the selected value, Is the transmission time delay of the lowest bandwidth link of the traversed path of the packet for a single packet to completely exit the transmission medium * the larger of the multiplicands: the “elapsed time interval” value here is always the above Note that it must be greater than the “synchronization” value of). Thus, if both ends are changed and each sends a “synchronization” packet to the other changed end, each end of both changed end TCPs will have an “elapsed time interval” in the subflow. One-way from the other end to the local end TCP when it expires and no packet of any type from the same subflow has been received from the TCP at the other end (including the "synchronized" packet type generated for the subflow) The path does not include congestion events and / or packet drop events and / or physical transmission error events and / or very rare and very sudden congestion level increase events (but here rare 200ms Delayed ACK events: Only one of the two ends is changed, and the other unchanged end TCP, for example, the other unchanged end TC When sending a "synchronization packet" in the form of a DUP Sequence Number packet outside the normal window that triggers a return response ACK returning from P, the local modified end TCP is the local modified end TCP. Either the forwarding path or the returning path between the TCP and the other unmodified end TCP (which is certainly not known), congestion event and / or packet drop event and / or physical transmission error Can only immediately know / infer / detect that an event and / or a very rare very sudden congestion level increase event (but not including a rare 200ms Delayed ACK event here) Should know / infer / detect immediately that they have met. This additional reliable detection / reliable reasoning that the one-way path from one end to the other and / or the other end to this end is indeed “UP” or indeed “DOWN” at this time is Should be useful to react better. This is practically useful to keep in mind that if the return one-way route happens to be “DOWN”, there is no way to know if the one-way route to go is “UP” or “DOWN”. It may or may not be used. Also, between lost-to-packet (physically arrived) packets, for example, due to the arrival of other late-ordered physically arriving packets within the “elapsed time interval”. Any missing “gap” packets that have not expired the delay “elapsed time period” of the packet that would normally be taken care of through the normal three DUP ACK fast retransmission mechanisms: Alternatively, the inter-packet arrival delay “elapsed time interval” mechanism can instead be used to determine the “elapsed time interval” from the arrival time of adjacent predecessor packets in order (eg, by ordering by packet sequence number ...). The main requirement is that all missing “gap” packets must trigger the “elapsed timeout” expiration if not received within It can be. . . Please note that.

  The subflow inter-packet arrival delay “elapsed time interval” expires and all types of packets from the same subflow (but the generated “synchronized” packet type of that subflow or the corresponding subflow of that subflow, if applicable) When no return response ACK has occurred, the local end modified TCP is combined with the existing CDNW decrease / rate decrease as described in the previous method / subcomponent method of this body description. Various changes with or without actual packet retransmission and / or modified isolated CWND reduction / rate reduction without actual packet retransmission and / or accompanying CWND reduction / rate reduction The “pause” method. . . , Etc., to trigger immediately and have the modified TCP at the local end do these (and / or optionally have the TCP at the other end do these "remotely"), or all from the same subflow Type of last / latest packet (but excluding the generated "synchronized" packet type of that subflow or the corresponding return response ACK of that subflow, if applicable) from the modified TCP at the other end Received (and all types of subsequent new intervening arriving packets from the same subflow (but the generated "synchronized" packet type of that subflow or the corresponding return response ACK of that subflow if applicable) Is not received from the modified TCP at the other end in this eg 250ms time). . . And / or the entire current valid window of packets of the same subflow has been transmitted and has not yet been acknowledged and returned for some further period, eg 250 ms (user input value or RTTest, It can be done either after a certain value (based on an algorithm including factors such as OTTest, RTTest (min), OTTest (max) ...) has passed.

When both ends implement the “inter-packet arrival” method and the “synchronization” packet method, the “synchronization” packet sent to the other modified end TCP is modified, for example, received by other Data field portion or inserted “padding” field, including, for example, source IP address port number and / or destination IP address port number, without requiring the end TCP to generate a response ACK to return Special fixed-length unique identification within a part. . . The same source IP address port number and the same destination IP address and port number as the TCP connection for each specific flow, with appropriate identification to uniquely identify such packets as “synchronized” packets, etc. And can be in the form of a generated packet. If only one of the ends is changed and the other end is unchanged (but applicable even if both ends are changed), the changed end will point towards the other unmodified end The “synchronization” packet when sent is identical to the TCP connection for a particular flow, for example, with a duplicated Sequence Number field that is not in a window that does not trigger a return response ACK from the receiving unmodified end. The source IP address port number and the generated packet with the same destination IP address and port number, such as a packet that triggers a return response ACK from the receiving unmodified end (eg Sending Seq No packet out-of-order that is not in the window where the TCP that receives is always “does nothing” and generates a return ACK Throat. Internet newsgroup topic "Acking out of Order packet" http://groups-beta.google.com/group/comp.protocols.tcp-ip 1 Phil Karn 1988 March 2, 2 CERF 3 May 1988 2 days ... See Google Search term “ACKing the ACK.” Note also that the transmission of a single DUP ACK does not cause a fast retransmission, or instead, for example, Out of order transmission of ACK, etc. Google Search terms “out of order ACK”, “eliminating an ACK”, “DUP Sequence Number ACK”, “ACK for un cent data ”,“ unexpected ACK ”, etc.). The triggered returned response ACK from the other unmodified end simply has its ACK field value from the modified end to the next expected Seq number received by the other unmodified end. Upon receipt of this return response ACK, the modified end will receive this returned response ACK because the data segment for this next expected sequence number has not yet been transmitted. It should simply be discarded and ignored. In this very rare “rare” scenario, where the next expected sequence number data segment was actually sent at the very moment before the returned response ACK was received, the modified end Is now only “unnecessarily” fast retransmitted when and after receiving three return response DUP ACKs, all with exactly the same ACK number, which is also very very likely Is low. This is because the data segment actually transmitted at the very moment before receiving the first returned response ACK and / or the subsequent subsequent transmitted data segment is now the next of the other unchanged end. This is because the expected sequence number should be incremented so that the next return response ACK now carries a different larger incremented ACK Number field value.

  The preceding paragraph above mainly described a scenario where the TCPs at both ends implement a “synchronize” packet transmission to the TCP at the other end. This is necessary when each end TCP does not receive any packets of the same subflow from the other end TCP (including the generated “synchronization” packets for the same subflow) and the “elapsed time interval” expires. The one-way path from the other end TCP to the local end TCP is congested and / or packet dropped and / or physical transmission error and / or very rare and very sudden congestion level increase (but in this case Since a “synchronize” packet mechanism is implemented, the 200 ms Delayed ACK mechanism is not currently responsible). A more complete combination scenario includes the following (assuming that the modified TCP at both ends further includes a “synchronize” packet method):

  1. "Elapsed time interval" has been changed at the local end without receiving any packets of the same subflow (including both of the "synchronized" packet types generated for that subflow) from the modified TCP at the other end When it expires in TCP → It knows / infers that the one-way path from the modified TCP at the other end to the modified TCP at the local end is “DOWN” → The modified TCP at the local end is Now it must react immediately and / or react accordingly to the modified TCP at the other end.

  2. The one-way path from the modified TCP at the other end to the modified TCP at the local end is “UP”, ie, consecutive packets (and / or “synchronize” packets) are “elapsed time intervals”. And the expected acknowledgment (for data packets sent by the modified TCP at the local end) when received from the modified TCP at the other end without expiring The local end changes if it is not received back from the modified TCP at the other end within a rate decrement timeout, combined RTO packet retransmission timeout, separated ACK timeout ... causing "pause", etc. TCP now has "DOWN" as the one-way path from the TCP at the local end to the TCP at the other end. With solid knowledge / solid reasoning Rukoto immediately react accordingly, it must be reacted accordingly in and / or the other end of the modified TCP.

If only one end of the TCP connection implements the "synchronous" packet method, then in this situation, the modified TCP implementing the "synchronous" packet method is traditionally changed from the unmodified TCP at the other end. The above can be adapted by having the unmodified TCP at the other end send a “synchronization” packet in the form of a “packet” that triggers an acknowledgment response (for example, the receiving TCP must do “nothing” “Out-of-order SACK No packet transmission within a window that generates a return ACK, etc. Internet newsgroup topic“ Acking out of Order packet ” http://groups-beta.google.com/group/comp.protocols.tcp-ip 1 Phil Karn 1988 March 2, 2 C RF 1988 March 2, ....., and see Google Search term "ACKing the ACK." Want to send a single DUP ACK is should also be noted that not cause the high-speed re-transmission. Alternatively, Instead, for example, out-of-order ACK transmission, etc. Google Search terms “out of order ACK”, “eliminating an ACK”, “DUP Sequence Number ACK”, “ACK for unsent data”, “unexpected ACK”,. Etc.)

  The “synchronized” packet method uses a TCP that is changed at the local end to a TCP at the other end (for example, half of the “elapsed time interval” value, etc.) that is shorter than the “elapsed time interval” value. It must be ensured that there is at least a “packet” to be transmitted. When both ends implement the “synchronized” packet method, both modified TCP protocols are, for example, during or immediately after the TCP connection phase. . . Detection of each other's presence, agreement of "synchronization" interval parameters, etc. . . Etc. can be preferably made possible. However, in this case, when no packet is received from the unmodified TCP at the other end within the expiration of the “Elapsed Time Interval”, the modified TCP at the local end will receive one of the one-way paths (but the local end It is not certain which one is “DOWN” from the modified TCP to the unmodified TCP at the other end or from the unmodified TCP at the other end to the modified TCP at the local end (both ends are modified and “synchronized” Can only be reasonably inferred (compared to when performing packet techniques).

  Adapting the various methods / subcomponent methods presented in this previous description to the use of the “Elapsed Time Interval” method and / or the “Synchronized” packet method, for example, rather than a separate rate decrement during ACKTimeout (I.e. not monitoring for acknowledgment of transmitted Seq No segments not received within eg non-congested RTT * multiplicand to react accordingly) "elapsed time interval" of every next packet received Are monitored instead). This allows for a much faster response time ("Elapsed Time Interval") than possibly a much longer non-congested RTT * multiplicand.

  When the time stamp option is selected, this is derived from both latency of one-way path delay (ie, RTTest and RTTest (min) ... etc. as well as OTTest and OTTest (min) ... etc.). Should be able to react better accordingly. The SACK option should allow fewer unnecessary retransmissions of packets that are already received out of order. "Synchronize" packets and / or earlier periodic probe packet methods, if necessary, are assigned a destination IP address and port and an unused port number that is unchanged but now is different on the source port. Can be sent independently in the form of a new TCP connection established between the per-TCP flow (s) with the source IP address.

  Note: “Between packet arrivals” (and / or optionally) “synchronous” packet method within each of the per-flow TCPs, eg after only the initial Sync / Sync ACK and / or a few n consecutive Only after a packet has been received from the other end TCP (whether modified or not) and / or all within the "elapsed time interval" from each other immediately preceding packet, a small number of m When certain criteria / events are satisfied, such as only after successive packets have been received from the other end TCP, they can operate to stabilize within the TCP for each flow. When the “synchronization” interval expires and a transmission of a “synchronization” packet is required, the modified TCP at the local end has not yet been acknowledged in place of the pure “synchronization” packet, previously The transmitted normal data packet (s) can instead be retransmitted / retransmitted to the other end TCP (this should also trigger an acknowledgment response returned from the other end TCP). is there).

  While one or more of the methods herein extend our modifications / invention to be applicable when either one (or both) of the source sender or receiver is present on the external Internet, It should be noted that, as well as the various previously described methods of this description body, it is also applicable when both are in the Internet subset / WAN / LAN / Proprietary Internet.

  A user interface is provided in the modified TCP / modified monitor software / modified TCP forwarder / modified IP forwarder / modified firewall described in various earlier sections of this description for various TCP tunings. / User input of registry parameters (eg, initial ssthresh, initial RTT, MTU, MSS, Delay ACK option, SACK option, Timestamp option ...), proprietary LAN / WAN subnet IP addresses (source and destination within these subnets) In order to be able to ascertain packet traffic that has both traffic to and from the external Internet as “internal traffic”. User input with ACKTimeout and / or “elapsed time interval” and / or “pause-interval” and / or “synchronization” interval between each and all address addresses (for better performance, eg Packet traffic to / from a common TCP port (rather than using only the maximum ACK timeout value, for example, equal to the maximum non-congested RTT * multiplicand between the most distant node pairs) And / or any additional TCP ports used and / or any source or destination port excluded from such special processing (e.g., some multimedia streams are TCP with specified port number instead of UDP User input). . . Etc. can be made possible.

  Here is an overview in several scenarios among the many different possibilities of the method / subcomponent method and / or inter-packet arrival method and / or "synchronized" packet method combination described in this description. There are some example cases only (if both ends are changed if only one end of the TCP connection is changed, this is obviously after both ends have detected the presence of each other's change. Make the task much easier).

  1. A modified TCP at the local end that acts as a sender source to the external Internet. The TCP stack is changed directly.

  During a “trigger” event (eg, 300 ms “Elapsed Time Interval”, 3 DUP ACKs, RTO actual packet retransmission timeout, etc.), among other possibilities, this is because TCP itself Allow a few packets to be transmitted during a pause to only “pause” (or not pause at all) and / or act as a probe during a defined pause-interval, and then CWND / rate Resume without changing the limit (or continue without a pause), eg 5%, 10%, 50%. . . Should only need to do or reduce the CWND / rate limit by x%.

  Here, when “pause” is performed, for example, when 300 ms “between packet arrivals” expires, the sender-based change, for example, 300 ms “between packet arrivals” expires, is sent by the local end sender to the other end. The benefit of knowing whether it was due only to the fact that it does not have a data packet to do and therefore does not need to “pause” unnecessarily and / or does not need to react unnecessarily accordingly. (Note that if the local end acts as a receiver, the local end may be due to a "trigger" event, e.g., a 300 ms "packet arrival" expiration, or simply the sender at the other end temporarily (Compare that there is no way to know if it has no more data packets to send).

  The inter-packet arrival method can be used instead of the “non-congested RTT * multiplicand” method as a triggering event to react accordingly, and in addition the “synchronized” packet method (here the local end is modified). Link that is generated only from the source TCP that sends it, but triggers a response such as a return ACK from the unmodified TCP at the other end) and / or a time stamp option is incorporated. Should be able to reliably detect / infer whether is indeed “DOWN” or indeed “UP”.

  2. A modified TCP at the local end that acts as a sender source to the external Internet. The TCP stack cannot be changed directly.

  Modified software monitor / modified TCP proxy / modified firewall as described herein. . . Would need to perform this task instead of the TCP stack itself. During a “trigger” event (eg, 300 ms “Elapsed Time Interval”, 3 DUP ACKs, RTO actual packet retransmission timeout, etc.), among other possibilities, this is described herein. Modified software monitor / modified TCP proxy / modified firewall. . . Only “pause” the intercepted TCP packet transfer during the defined pause-interval and / or allow a small number of packet transmissions during the pause to serve as a probe and then resume For example, a “spoofing” a fixed number of ACKs for all incoming intercepted outgoing TCP packets (for example, the possibility of resetting to 1 segment size when re-entering “slow start”) To quickly restore some TCP's CWND / rate limit) and / or, for example, a modified software monitor / modified TCP proxy / modified firewall. . . Etc. (rather than the TCP itself that should not even be required to retransmit any of the packets that are now sent), such as the actual packet retransmission of all fast retransmit 3DUP ACKS / RTO timeouts, such as Do not forward DUP pure ACK to TCP and / or remove all fast retransmit DUP ACK packets by removing ACK bits in piggybacked DUP ACK packets while recalculating checksum before forwarding to TCP Even processing by keeping an actual copy of the window of data being sent while being suppressed and / or TCP is RTO timeout. . . "Spoof" the ACK to the TCP just before . . Should only require. Here, when “pause” is performed, for example, when 300 ms “between packet arrivals” expires, the sender-based change, for example, 300 ms “between packet arrivals” expires, is sent by the local end sender to the other end. The benefit of knowing whether it was due only to the fact that it does not have a data packet to do and therefore does not need to “pause” unnecessarily and / or does not need to react unnecessarily accordingly. (Note that if the local end acts as a receiver, the local end may be due to a "trigger" event, e.g., a 300 ms "packet arrival" expiration, or simply the sender at the other end temporarily (Compare that there is no way to know if it has no more data packets to send).

  The inter-packet arrival method can be used instead of the “non-congested RTT * multiplicand” method as a triggering event to react accordingly, and in addition the “synchronized” packet method (here the local end is modified). Link, which is generated only from the software, but elicits a response such as a return ACK from the unmodified TCP at the other end) and / or a time stamp option is incorporated, It should allow reliable detection / inferring whether it is “DOWN” or indeed “UP”.

  3. Local end modified TCP acting as a receiver from an external Internet sender source. The TCP stack is changed directly.

  The inter-packet arrival method can be used instead of the “non-congested RTT * multiplicand” method as a triggering event to react accordingly, and in addition the “synchronized” packet method (here the local end is modified). Link) is generated only from the receiver TCP, but elicits a response such as a return ACK from the unmodified TCP at the other end) and / or if a time stamp option is incorporated, the link in which direction is Should be able to reliably detect / infer whether it is “DOWN” or indeed “UP”. In addition, a technique such as Divisional ACK / DUP ACK / Optimistic ACK can be used to increment the CWND / transmission rate of the source TCP to send unchanged at the other end whenever necessary, and the window size update packet technique Can be used to “pause” the unmodified sending source TCP at the other end. . . Etc.

  4). Local end modified TCP acting as a receiver from an external Internet sender source. The TCP stack cannot be changed directly.

  Modified software monitor / modified TCP proxy / modified firewall as described herein. . . Would need to perform this task instead of the TCP stack itself. During a “trigger” event (eg, a 300 ms “elapsed time interval” for a particular subflow), among other possibilities, this is a modified software monitor / modified TCP proxy / Modified firewall. . . Only allows the sender TCP at the other end to “pause” the packet transfer of that particular subflow remotely during the defined pause-interval and / or a few during the pause to act as a probe. When packet transmission is enabled and then resumed, for example, a fixed number of DUP ACKs are quickly sent to the sender TCP at the other end (eg reset to 1 segment size when reentering “slow start”) Only to quickly restore the TCP CWND / rate limit of the other possible TCP). The inter-packet arrival method can be used instead of the “non-congested RTT * multiplicand” method as a triggering event to react accordingly, and in addition the “synchronized” packet method (here the local end is modified). Link) is generated only from the receiver TCP, but elicits a response such as a return ACK from the unmodified TCP at the other end) and / or if a time stamp option is incorporated, the link in which direction is Should be able to reliably detect / infer whether it is “DOWN” or indeed “UP”. Additional techniques such as Divisional ACK / DUP ACK / Optimistic ACK can be used to increment the CWND / transmission rate of the unmodified source TCP at the other end whenever necessary, and the window size update packet technique Can be used to “pause” the unmodified sending source TCP at the other end. . . Etc.

  The TCP connection is symmetric, i.e. the local end can both send and receive data at the same time (even if the actual data is not sent at all, always the other end So there is a back ACK generated towards the local end) modified TCP / modified monitor software / modified TCP proxy / modified firewall at the local end. . . Etc., of course, can simultaneously act as both sender-based and receiver-based. Further, if all of the ends are changed, each end can still act as both a sender-based and a receiver-based at the same time and can work together: but preferably and / or alternatively If they detect the presence of a change in each other, these ends work only by acting only as sender-based only, each acting only as receiver-based, or only one end as both receiver-based and sender-based. It can be agreed that the modified action at the other end is disabled. An example of many possible ways of detecting each other's altered presence is to send, for example, a packet with a special unique fixed length identification pattern in a “padding field” or fixed length data portion to the other end. It is.

Example methods derivable from a combination of various methods and / or subcomponent methods disclosed in this description (measurements such as various one-way trip times OTT, OTTest and estimated non-congested OTTest (min) ...) Enabling estimation may require negotiating a timestamp option during the TCP connection establishment SYNC / SYNC ACK phase, from the sending source to the receiver for a particular sent segment / packet. The one-way trip time OTT can be derived by the sender from the various time stamp field values of the corresponding ACK returned: Obviously, the OTT value, OTTest value, OTTest (min) value is the source or receiver sending Can be used from either Should allow better and more efficient transmission control because RTT, RTTest, RTTest (min) are introduced by the asymmetry of the forward and return paths. Because the element is inherently included).

  (A) Latest non-congested RTTest (min) and / or latest non-congested to detect when packets start to be buffered and / or the beginning of packet loss in a proprietary network such as LAN / WAN / Proprietary Internet OTTest (min). . . Such as sender-based monitoring.

  In a proprietary network, all the PCs / servers in the proprietary network are required to enable the guaranteed service function. . . (Or just a substantial number of high traffic sources) to install any of the previously described modified TCP upgrades or monitor software (or application software present on their PC / server ... etc.) Make these changes directly within the application, eg, directly within the RTSP streaming application). . . Etc.

  The non-congested RTT value or the non-congested OTT value between all all subnets is known in advance in the proprietary network (the non-congested RTT value or the non-congested OTT value is different for data packets of different sizes, especially for media links such as ISDN Most TCP packet sizes are pre-negotiated during the TCP connection establishment phase and generally negotiated maximum segment size MSS values of about 800 bytes, 1500 bytes. Note that the modified TCP upgrade or monitor software of this specification. . . For example, a non-congested RTT or a non-congested OTT time period of a specific source-destination flow + a specified time period B returns a corresponding ACK of a specific transmitted packet (s) The transmission rate of each individual TCP flow can simply be throttled back (e.g., through a "pause" period or through a CWND window size percentage decrement ...). . The time period B here is introduced cumulatively while buffered at various nodes along the traversed path and corresponds to the total packet buffer delay experienced by the packet: Setting a short period of time should ensure a very good guaranteed service level enjoyed by other real-time critical VoIP / videoconferencing UDP packets. This is because the UDP packet in this case is unlikely to encounter a cumulative total buffer delay much more than 20 ms along the various nodes traversed. Setting B = 0 in this case ensures that the TCP flow always tries to avoid all the beginnings of packet buffering delays immediately, when the network is not buffered or happens to happen. Keep only a very small buffer delay during an occasional interval. The TCP rate throttle decrement percentage can be set to various fixed values, or can be derived algorithmically to be various dynamic values, eg, (B ms + eg T ms ) / 1000 ms, where B = 50 ms and T = 50 ms, the rate decrement percentage here is 10%, ie the TCP transmission rate is now throttled back to 90% of the existing transmission rate → Therefore, assuming that the flow traversing the bottleneck link now does not increment or decrement its transmission rate at all, then the throughput level of that bottleneck link is now the bandwidth of that bottleneck link. It can now be seen that it is maintained near the steady 90% capacity. Another possible non-exhaustive example of the value derived by the TCP rate throttle decrement percentage algorithm could simply be, for example, the non-congested RTT value of the flow per B ms / TCP, where B = 50 ms. And at non-congested RTT = 400 ms, the rate decrement percentage here should be 12.5%. The time period T ms is / can be added here before, so that using a larger rate decrement percentage, the flow traversing that bottleneck link (usually the case with TCP) Incrementing its transmission rate as is now taking more time to reach again above the 100% link throughput level, and then requires buffering, which is It should then slightly affect other real-time critical guaranteed service UDP packets.

  Modified TCP upgrade or monitor software. . . Etc., whenever required, the desired desired after various designated “trigger event (s)” (eg, met B ms cumulative total buffered delay, etc.) (Eg, 100%, 99%, 95%, 85%, etc., rather than the current 100% utilization level with associated packet buffering delay). To subsequently cause bottleneck link bandwidth utilization), via CWND percentage decrement and / or through “pause” in such a manner. . . And so on, can provide a flow (s) rate throttle per TCDP. Various algorithms, policies and procedures can be further devised to handle all types of “trigger events” in a variety of different ways.

  Where the modified TCP upgrade or monitor software. . . Note that prior knowledge of inter-subnet non-congested RTT and inter-sub-net non-congested OTT is not necessarily required between the various subnets in the proprietary network. Rather, here is a modified TCP upgrade or monitor software. . . Store the current latest observed minimum RTT value of the flow for each individual TCP or the current latest observed minimum OTT value and store this as the non-congested RTT of the flow for each individual TCP or It can be treated as dynamically equivalent to non-congested OTT. Common sense upper and lower bounds for these RTTest (min) or OTTest (min): For example, these maximum upper ceiling limits can be set to the RTTmax values of known farthest-position pairs in the proprietary network . . . Etc.

(A1) Latest non-congested RTTest (min) and / or latest non-congested to detect that packets start to be buffered and / or the beginning of packet loss in a proprietary network such as LAN / WAN / Proprietary Internet OTTest (min). . . Receiver-based monitoring such as remote ACK division / multiple DUP ACK / optimistic ACK, window size updates of various sizes to cause “pause (s)”, and via duplicate packet method Initiate ACK response, 3 DUP ACKs to trigger fast retransmission to preempt RTO retransmissions, etc. Previous receiver based method / subcomponent method using ... From the various methods / subcomponent methods described in this section and in various parts of this description body).

(B) The latest non-congested RTTest (min) and / or for detecting the beginning of packet buffering and / or the beginning of packet loss in proprietary networks such as LAN / WAN / proprietary Internet and / or external networks Or the latest non-congested OTTest (min). . . Sender-based monitoring such as The external Internet receives other existing unmodified TCP flows that are not in control, such as in a proprietary network. The above example (A) (s) would need to be further modified to take this into account.

  CWND percentage decrement and / or “pause (s)”. . . The “trigger event” for causing rate throttle decrement via, for example, 100% / 99% / 95% / 85%. . . Need to be further modified, such as not incrementing during the specified or dynamically algorithmically derived s seconds after fallback to, etc., once again the bottleneck link throughput utilization is % Triggering the start of packet buffering delay within the above s seconds, “trigger event (s)” (packet drop / buffering delay threshold exceeded, etc.) Until the transmission rate starts to increment / increase again, otherwise it starts to allow increment / increase of the transmission rate after s seconds have passed. Various algorithms, policies and procedures can be further devised to handle all types of “trigger events” in a variety of different ways.

  Here, on the external Internet, where non-congested RTT and / or non-congested OTT is not readily known in advance for newly established per-TCP flows, this is why the current latest observed RTTest (min) or OTTest. (Min) should instead provide a dynamic estimate equivalent to the non-congested RTT and / or OTT value.

  Existing standard TCP emphasizes fair share and friendliness of competing TCP flows, but only after a single packet drop RTO timeout or especially on long distance fat pipes with high bandwidth and long RTT latency. After 3DUP ACK fast retransmissions, the very long period required to re-achieve previously established transmission rate / throughput (mainly achieved Ssthresh CWND size during slow start exponential CWND increase Inefficient in full utilization of available bandwidth for maximum throughput, as evidenced by conservative linear CWND increments of existing TCP in later congestion avoidance modes). The new and improved criteria for modified TCP are now not only inefficient and slow very friendly fair sharing, but also high available bandwidth and / or high available buffers for maximum TCP throughput Must include usage. The modified TCP ultra-fast response time here (to 1 second of the dynamically derived RTO value) to “pause” and / or reduce CWND during various “trigger events” The default minimum lower ceiling value (not the default minimum ceiling value) should minimize the packet drop percentage, and the “continuous pause” described above also gives the transmission rate decrement size very flexible, ie, eg 64 Kbytes per RTT For example, should be reduced to only 40 bytes per 300 ms).

  The modified TCP herein is in a number of different different ways than in CWND incremental sizes (and / or equivalent “pause” intervals, “continuous pause” interval settings, eg, smaller values). It can be aggressive. CWND is incremented by a specified integer multiple or dynamically derived integer multiple MSS per received ACK and / or RTT rather than per MS ACK received and / or RTT of the existing RFC, for example Can be initialized to a specified value and / or permanently to a very large value, such as to be the same as the maximum window size negotiated during the TCP connection phase. Can be fixed. . . Etc. "Trigger event" (packet drop (s) combined / separated RTO timeout, 3DUP ACK fast retransmission, separated when ACK is returned outside externally set specified interval The modified TCP has a bottleneck link (s) utilization of, for example, 100% / 99% / 95% / 85%. . . Can be tried to decrement the rate to ensure that it is maintained at high throughput, etc. or even at various congested buffering delay levels above 100% (all traversing paths) (Assuming TCP is all modified TCP).

  As an example of the many possibilities, the modified TCP (in either or both the sender and the receiver) of this specification is a non-congested source-receiver-source RTT value or non-congested source-receiver. Should have prior knowledge of the OTT value, or the dynamic best estimate RTTest (min) / OTTest (min) equivalent above: Each of all links traversed will have its respective 100% usable bandwidth RTT value or OTT value or RTTest (min) value or OTTest (min) value derived from the returning ACK, for example, when packet buffering does not occur at any of the traversed nodes, It is now the same as the actual actual non-congested RTT value or non-congested OTT value (below With a very small random variation introduced by the node processing delay / source or receiver host processing delay, etc., referred to as ms: this value V ms variation is usually specified or dynamically derived B Should be smaller than other previously described system parameters such as ms ..., etc. V ms will be short and very large if not expected on very rare occasions eg Windows OS is real time It is not an OS ... which can instead be treated "exceptionally" in the same way as it is caused / introduced / caused by the node buffering delay encountered instead). For example, as long as the RTT value or OTT value or RTTest (min) value or OTTest (min) value derived from the returning ACK continues to indicate that there is no buffering delay encountered along the path (s) traversed The modified TCP can either continue conservatively tolerating transmission rate increments / increases like existing RFCs, or it can continue to increase / increase more aggressively. When a certain level or levels of buffering delay (s) indicated / derived from the back ACK is exceeded, ie, [(back RTT or OTT)-(RTTest (min) or OTTest (min))] The value of indicates the cumulative total buffering delay (s) encountered at various nodes along the path (s) that are now traversed (hereinafter referred to as C ms). For example, the value of C is 20 ms / 50 ms / 100 ms. . . The modified TCP can now reduce, for example, the transmission rate, for example, so that the link utilization of the bottleneck (s) is then reduced to those bottleneck links (one Assuming that all TCPs traversing (or multiple) are all modified TCPs, eg 100% / 99% / 95% / 85%. . . (Now knowing the latest estimated equivalent of the actual non-congested RTT or non-congested OTT of the flow per TCP and the value of C, so the required CWND decrement percentage and / or Or a “pause” interval or a suitable sequence of necessary “pauses” can now be verified to achieve the desired desired end result). The modified TCP now stops all further rate increments / increments of the TCP flow, for example during the period s seconds (specified or dynamically algorithm derived) as described previously, and then For example, it can respond accordingly in a variety of different ways as previously described or further devised. This particular example has the effect of achieving high utilization throughput in addition to the friendly fair sharing of existing RFCs, and correlates the cumulative buffering delay of the traversed path (s) to the C value. To keep being maintained at a low level: in the absence of other strong dominant unmodified TCP flows (in which case the modified TCP flows herein will rate within s seconds) Increment / increase should be allowed to begin), together with all other unchanged TCP flows, will eventually trigger a packet drop event: It would take a very long time to re-enter “slow start” and re-achieve the previously achieved transmission rate, but the modified TCP flow has been achieved previously. We were able to hold any high ratio of the transmission rate / throughput (resolve existing response issues particularly related to the long RTT long distance fat pipe). New TCP flow (s) (and / or other new UDP flows, eg, with modified TCP rate decrement to achieve subsequent 95% bottleneck link (s) utilization (One or more), etc.) can always be used to initiate a flow rate increment / increase without introducing packet buffering delay (s) along the route (both bottleneck links ( One or more) up to 5% of the bandwidth should be immediately available, and the bottleneck link (s) are new in the X millisecond equivalent of available bandwidth without discarding packets. It should be able to deal immediately with additional sudden instantaneous traffic surges (most internet nodes typically have a buffer size equivalent to between 300 ms and 500 ms). Having's): This allows for common wisdom and at the same time consistent, increase in the new additional flow as progressive control of saving the established throughput of an existing flow.

  Alternatively, the modified TCP rate conservatively or more aggressively like the linear increase of the existing RFC (rather than throttling back when a cumulative total buffering delay of C ms is detected, etc ...) Incremental / increase is always possible and can only be throttled back accordingly during a “packet drop” event: this is only for the benefit of maximizing the throughput of the TCP flow, and other real-time Although it should not be good for critical UDP flows, the traversed node can make a real-time critical UDP packet emergency by simply reserving a guaranteed minimum percentage of available physical bandwidth for UDP packet priority forwarding. Easy guarantee of guaranteed service performance. . And so on.

  The website server / server farm can advantageously implement the modified TCP implementation described above. A typical website is often optimized to be about 30-60 Kbytes for speedy downloads (about 5 Kbytes / second without being interrupted continuously by packet (s) drop) For analog 56K modems, etc. that you download with, this still takes about 6-12 seconds). Immediately after the SYNC / SYNC ACK / ACK TCP connection establishment phase, the modified TCP of the sending source server is the current latest observed minimum source-receiver-source RTTest (min) or source-receiver OTTest (min). The very beginning of the non-congested RTT or non-congested OTT of the flow (s) per TCP, in the form of a value (regardless of whether it represents an actual non-congested RTT or non-congested OTT value) Should have an estimate of The modified TCP of the sending source server can optionally start immediately from the CWND window size of now W segments and immediately start sending the very first data segment / packet, eg , Using the negotiated maximum segment size MSS of approximately 1600 bytes and W = 20, it would only take 2 * RTT to receive all of the 60 Kbytes of content by the client web browser (packets on transmission ( One or more) is not thrown away, broken, and the minimum link bandwidth along the path is the end user's last mile 500 Kbit / s broadband). With W = 64, the client web browser may only require 1 RTT or 1 OTT to completely download 60 Kbytes of website content (a normal Internet RTT may be on the path (s)) Including the delay (s) introduced by buffering along, typically from about tens of milliseconds to hundreds of milliseconds). If the minimum link bandwidth along the path is the end user's last mile 56 Kbit / s analog modem dial-up, the above time period will only transmit up to about 5 Kbytes per second over the last mile link. It should have been at least 6 seconds or 12 seconds (before 30 Kbytes or 60 Kbytes of segments / packets are sent forward to the end user's web browser via dial-up. First, assuming the end user's last mile ISP is buffered by the AOL web proxy server). Exactly in the worst case, segments / packets for the first 20 or 64 MSS CWND windows will immediately cause a buffer overflow, so that those segments / packets will be on the bottleneck link (s). Even if discarded, the modified TCP of this document (for example, halves or guarantees an extended period of bandwidth utilization instead of the existing RFC rate), for example, some level of subsequent bottleneck links (1 Rate decrement to ensure utilization / throughput, and / or more controlled aggressive subsequent rate increment / increment, and / or more controlled buffer delay level congestion avoidance (e.g., "packet It is not the only existing RFC method that waits for the drop (s). Wait s seconds before allowing the door incremental / increase ..., etc.). . . And so on, can be responded reasonably quickly in the form described above / shown shortly (much faster than the minimum minimum floor default response time of existing RFCs of 1 second minimum).

  The modified TCP, ie the modified TCP for the web server is the monitor software / proxy TCP. . . This is essentially simply the various earlier methods / subs of this description, when it needs to be implemented in a form such as (without direct access to the host TCP stack source code for modification) As described in the component method, the monitor software / TCP proxy residing on the sending source server is controlled by the resident sending source server's TCP stack to increase the CWND window size / send rate more aggressively. On the other hand, it is required for the resident sending source server's TCP stack to "spoof ACKs" whenever requested and / or to temporarily stop sending or decrement the sending rate. Sometimes spoofs zero or small receiver window size update packets and / or Is the forward forwarding of intercepted TCP-originated packets by the monitor software resulting in equivalent transmission rate decrement via “pause” / “continuous pause” (and / or one during each pause interval). Or a small number of packet transfers) and / or store all actual data segments / packets for the full window sent by the resident host's TCP stack, and then all combined or separated RTO retransmissions / 3DUP ACK fast retransmissions, freeing the resident host TCP stack from all such responsibilities and / or all actual multiple windows transmitted by the resident host TCP stack Stores data segments / packets and is therefore controlled by the monitoring software Multiple when "spoofing ACKs" to the resident host TCP stack and / or using ACK Division / multiple DUP ACK / Optimistic ACK techniques to do so to provide a more aggressive rate increment / increase Allows window segments / packets to be generated by the resident host TCP stack within a single RTT and / or inspects incoming ACK packets from the network and / or forwards them to the resident host TCP stack Respond accordingly, including whether to change various fields (ACK Number, Seq Number, Timestamp value, various flags, advertised window size, etc.) before discarding Inspect its RTT / OTT to check and / or. . . . . . . . Note that it should be necessary.

  Here, the monitor software / TCP proxy. . . Each with one single or a small fixed number of packets to act as a “probe”, while leaving the transmission rate controlled only through “pause” / continuous “pause” Using the combinations described above for techniques, methods, and subcomponent methods, the resident host's effective transmission window and / or CWND can be maximized to some required size or always, while allowing transmission during the pause interval. Note that even the negotiated window size can be kept permanently fixed.

  (Immediately after the SYNC / SYNC ACK / ACK TCP connection establishment phase, the modified TCP of the sending source server now starts immediately, instead using the existing RFC slow start 1MSS segment size CWND window. The transmission of the very first data segment / packet can be started immediately, but this is now done to complete the content transfer as is the usual general daily experience of the end user. A large number of RTTs, which may take several tens of seconds to several minutes).

(B1) The latest non-congested RTTest (min) and / or for detecting the beginning of packet buffering and / or the beginning of packet loss in proprietary networks such as LAN / WAN / Proprietary Internet and / or external networks Or the latest non-congested OTTest (min). . . Receiver-based monitoring such as remote ACK Division / multiple DUP ACK / Optimistic ACK and / or via various size window size updates and / or duplicate packet methods to cause “pause (s)” Previous receiver-based methods / subcomponents that use 3 DUP ACKs, etc. to trigger “do nothing” ACK response and / or trigger fast retransmission to preempt RTO retransmissions It is clear enough from the method and the various methods / subcomponent methods described in this section and the various parts of this description body, see the previous section on implementing TCP changes to work over the external Internet . Wanna)

  As an example, with the Timestamp option negotiated during the TCP connection establishment phase, the receiver's modified TCP or monitor software now has a source-receiver equivalent to the actual uncongested one-way trip time of the arriving packet. An estimate of the path, i.e. the current latest observed OTTest (min), can be derived. The cumulative total buffering delay encountered by any arriving packet, if present, can be derived by subtracting OTTest (min) from the OTT of the arriving packet (introduced by node packet processing / forwarding time upset). All neglected are usually very small random fluctuations). It is preferable to use the Selective Acknowledgment option and disable the Delayed Acknowledgment option (eg, depending on the host PC's TCP / IP registry entry settings, but these are not strictly strict requirements). The modified TCP or monitor software is now in the correct position and now provides an estimate equivalent to the actual non-congested OTT and buffering delay level of the uncongested source-receiver path and is friendly Should respond accordingly as desired to achieve maximum bandwidth utilization / throughput criteria while maintaining fair sharing (remotely “pause” and / or send source TCP “Continuous pause” and / or “unpause” while allowing one single packet transfer per pause interval and / or increment CWND size via Divisional ACK / Multiple DUP ACK / Optimistic ACK; And / or RTO tie via early 3DUP ACK fast retransmission Out to pre-empt, and / or ...... etc.).

  The previous example can be further simplified so that it does not require the use of the Timestamps option at all (ie, the arriving OTT value, the OTTest (min) value, and the derived cumulative total met buffering delay value). There is no need to do or use at all: the modified TCP or monitor software of the receiver will instead wait for the next packet to arrive after the arrival time of the most recent last received previous packet. If you can simply wait for a specified W millisecond (eg 250 ms) interval, and this does not arrive within W milliseconds, then the specified maximum bandwidth utilization / To achieve throughput criteria (but more aggressive than the previous example) as desired Then treat this as a “trigger event” (most likely the next packet was buffer overflowed congestion dropped) and then immediately (remotely “pause” to the sending source TCP, and Allow one single packet transfer per pause interval to “continuously pause” and / or “unpause” and / or increment CWND size via Divisional ACK / Multiple DUP ACK / Optimistic ACK And / or preempt RTO timeout via early 3DUP ACK fast retransmission and / or ... etc.) where the packet is sent to each of three different nodes A / B / C For example, you encounter 3 buffering delays of 300ms, then A “pause” of, for example, 250 ms on the sending TCP, when a buffer overflowed congestion drop occurs at another node D (eg having a buffer capacity equivalent to 400 ms) along the path, and is now node D In addition to reducing the buffer congestion level at the node A / B / C to only 150 ms, it should also reduce the buffer congestion level at each of the nodes A / B / C to only 50 ms each. The “pause” interval value derived in the above will certainly completely clear all buffering at each of nodes A / B / C / D (ie The packet is not buffered at all and is not congested), but the previous example is OT And OTTest (min) derived cumulative encounter buffering congestion delay knowledge, depending on the knowledge of the above values, can react accordingly with a finer level of control. Can be compared to presenting a more simplified example that can only react mainly after a buffer overflowed packet drop event (all buffers of all traversed nodes (equivalent to 400 ms each) Is consistently stable, even if it is close to overflowed but still not overflowed, the packet that immediately follows the last received packet is still , For example, 50 ms / 100 ms / 200 ms / 250 ms. . . Etc.)

  The current latest minimum observed elapsed interval E of the next packet that arrives since the last received packet (of any length), from length L = 1 to the negotiated maximum segment size MSS (L) is preferably stored, which means that a single packet of length L is the lowest bandwidth link transmission medium along the path (eg normal end user last mile 56 Kbs dialup or 500 Kbs broadband, this description (See also pages 192 to 195), giving us a knowledge / equivalent estimate of the transmission time delay to complete. The transmission time delay E (L) is expected to be linearly proportional to the packet length L. We now have a modified TCP or monitor software commensurately when, for example, (W milliseconds + maximum negotiated segment size MSS length packet E (L)) passes without packet arrival. For example, to assume that the E (L) of the packet with the maximum negotiated segment size MSS length has already been taken into account in the derivation / designation of the value of W, for example to respond W milliseconds can be specified so that it will only "trigger" the event to react accordingly.

  As another more simplified example among many, here, for example, much faster web page downloads, ftp downloads. . . Inter-packet arrival interval technique (which can be further modified / adapted and can be implemented directly in the TCP itself, not the monitoring software), giving better performance on the external Internet, etc. An overview of a very simplified receiver-based modified TCP that is utilized and implemented in the monitor software will be described.

  1. When receiving a TCP packet from a remote sender, be sure to check the source address and port if already in the TCP table for each flow, otherwise use the various parameters to check the TCP for each new flow. Create TCB (no need to maintain previous Seq No / Send Time Table entry for all intercepted packets).

  . Latest packet received local system time (received from remote sender; pure ACK or normal data packet), advertised window size of latest receiver packet (sent to remote sender by local MSTCP), latest receiver The ACK number of the packet, ie the next expected Seq number expected from the remote sender (which is sent to the remote sender by local MSTCP and requires inspection of incoming and outgoing packets per flow, and we now (It must be possible to immediately remove the TCP table entry for each flow during FIN / FIN ACK without waiting for second inactivity). . . Such.

  (Optional) Upon completion of Sync / Sync ACK, immediately set the remote sender's CWND to eg 64K bytes specified by the user or dynamically algorithmic, eg depending on the bandwidth capacity of the end user last mile link It is also possible to set a smaller or larger scaled size. For example 64K (this is the normal default maximum window size negotiated unless the window scaling option is selected, which compares the content of the remote external Internet website with the usual tens of seconds experienced. Can be downloaded within a single RTT only). This is preferably done via eg 15 immediate DUP ACKs with eg ACKNo = Remote Sender's initial SeqNo + 1, instead some TCP only increments CWND by the number of bytes ACKed instead. Thus, the Divisional ACK may not work well and the optimal ACK behavior may not be the same for all TCPs.

  Note: In the alternative, we wait for the first data packet received from the remote sender and then have an ACKNo set equal to the SeqNo just received from the remote sender (only one byte unnecessary Generate (for example, 15 DUP ACKs) or use a Divisional ACK (with retransmission expenses).

  TCP uses a 3-way handshaking procedure to set up a connection. The connection is set up by the initiator sending a segment with the SYN flag set and the proposed initial sequence number (seq = X) in the sequence number field. The remote then sets both the SYN and ACK flags, sets its sequence number field to its own assigned value in the reverse direction (seq = Y), and X + 1 acknowledgment field (ack = X + 1) Returns a segment with Upon receipt of this, the initiator stores Y, returns only a segment with the ACK flag set and a Y + 1 acknowledgment field.

2. If, for example, 300 ms (user specified or dynamically derived algorithm) expires without receiving the next packet,
→ We generate the next DUP ACK in the software with the next expected Seq No that has not yet arrived in the ACK No, for example within 300ms from the last received packet Detects that the expected Seq No has not arrived and at the same time conveys a window update of eg 1800 bytes within 3 DUP ACKs (equivalent to the sender's “pause” + 1 packet): eg 100 ms is pure ACK or normal If it passes without receiving any data packet, it only needs to keep sending the same 3 DUP ACK window updates of 1800 bytes incremented by 1800 bytes each time, but ACK or normal data packet is When it is actually received next time, an ACK or normal data packet is received from the remote. Repeats every 100ms until it is received again in the same single window update ( not 3 DUP ACKs) that restores the previous window size ( transmitted remotely from the local MSTCP to the ACKNo field ) Send the “recorded” latest “maximum” ACKNo or −1) and then repeat the above 300 ms expiration detection loop at the very beginning of step 2 above (optionally we First, at this point, before looping again, the maximum window size of 64 Kbytes, for example, negotiated to the CWND size of the transmitting source, here using the Divisional ACK / fixed number of DUP ACK / Optimistic ACK techniques Set / 32K bytes, or E is incremented by 16 DUP ACK the CWND size of the source to be transmitted if ... can such be).

  Here, we can also send 3 DUP ACKs instead of a single window update packet, but after 2 additional 100 ms, a single window update ACK packet has a total of 3 DUP ACKs. It should be a window update packet and, of course, the alternative here is to replace any window update packet, eg DUP SeqNo window update packet. . . Note that, and so on.

Various notes on some of the subcomponent techniques available:
. Starting from the first received packet after TCP connection establishment SYNC / SYNC ACK, current observed RTT-current latest recorded RTTest (min) or current observed OTT current latest record If the generated OTTest (min) is greater than a reasonable cumulative total buffering delay (eg, caused by a temporarily lengthened pause / gap in source packet generation), ignore such occurrences and Does not trigger "trigger event".

. CWND size percentage reduction, eg [(current observed RTT−current latest recorded RTTest (min) or current observed OTT−current latest recorded OTTest (min)) + T ms] / Current observed transmission rate decrement over RTT or OTT, but here using T = 0 ms implies that the throughput of the subsequent bottleneck link will be 100% of the available bandwidth. Note and / or [(current observed RTT−current latest recorded RTTest (min) or current observed OTT−current latest recorded OTTest (min)) + T ms]. Set pause interval. A distinction between the internal proprietary network subnet address and the external Internet to activate the corresponding appropriate method / algorithm. The inter-packet arrival technique can be adapted for use, similar to the “synchronization packet” technique.

  . For example, pathchar / pipechar / pathchirp. . . Bandwidth / link probing techniques such as can be deployed jointly to derive a finer level of knowledge of the traversed path / node / link and react accordingly better.

  . User input external internet connection speed to allow maximum window size negotiation, eg 5 Kbytes from dialup, but ISP even buffers 64 Kbytes / second and forwards to the user's 56 Kbs dialup, eg 5 Kbytes per second This can be very convenient when, for example, introducing a long traversed path, for example a few seconds of RTT or OTT.

  . A very fast reaction time that “pauses” / reduces CWND minimizes the packet drop percentage, and “continuous pause” also makes the transmission rate decrement size very flexible, ie for example from 64 Kbytes per RTT, for example Reduce to only 40 bytes per 300ms.

  . TCP is inherently unfair to high RTT flows, and we remove this using, for example, an interpacket interval technique.

. Suppressing multiple ACKs to reduce the transmission rate / throughput of the sending source TCP, ie a slight delay in forward forwarding to the sending source. Even after a buffer overflowed congestion packet drop and / or a physical transmission error packet drop by being able to maintain bandwidth capacity utilization / throughput of bottleneck link (s) close to 100% at all times The modified TCP is a very poor use of the bandwidth capacity of the link (s) from the existing RFC TCP (from the existing RFC TCP AIMD additive increase multiplicative decrease "saw tooth" utilization / throughput graph Compared to (as is very clear) good throughput / bottleneck bandwidth utilization can be doubled.

Further Notes and Further Methods The inter-packet arrival interval (eg, 300 ms) technique can optionally be activated only when less than the entire valid window is received / transmitted: otherwise 300 ms May elapse without receiving new packet (s), for example when OTT or RTT> eg 300 ms (because the returning ACK arrives back to the sender): eg current effective window size To check if it is greater than, less than or equal to, the latest received SeqNo—the latest transmitted ACK number may be checked.

  Optionally, after SYNC / SYNC ACK / ACK (or one or two of the first received normal data, so that the remote server does not time out and set CMSND and / or SSthresh to 1MSS or 2MSS. For example, 3 + DupNum DUP ACKs may continue to be transmitted every 500 ms after the packet. The sender TCP is eg due to a very sudden increase in the congestion level of the traversed path, for example the return ACK of the first normal data packet transmitted-the return ACK of the transmitted SYNC ACK RTT> C ms, eg 100 ms. ), The algorithm may or may not be used during the first 64K bytes of the data packet transfer.

Refined specifications :
First, set the registry entry, enable SACK much more preferably, and disable Delay Acknowledgment.

Command line input parameters:
-WaitTimeStamp (ms)-Interval between elapsed packet arrivals to infer "network congestion drop"-PauseTimeStamp (ms)-Remote server pause interval during "congestion"-DupNum-Remote server 3DUP ACK fast retransmission During the phase, the CWND size is further incremented for each additional DUP ACK received, and we use this technique to send a large number of DupNum DUP ACKs to ramp up the CWND.

  -Offset-0 or 1, the ACKNo field in the DUP ACK will work if the latest updated dwACKNumber recorded (ie the latest maximum ACKNo sent by the receiver MSTCP to the remote server) is set Is not very sure, or only works after subtracting one byte.

1. Procedure to handle outgoing TCP packets (packets from our MSTCP to remote hosts) Create a new entry for the TCP connection for this packet if necessary. I have to record several variables:

-DwACKNumber (when ACK flag is signaled)-ACK field in TCP header-dwSEQNumber-Seq Number field in TCP header-dwTCPState-This TCB variable can be used to control the TCP connection state in any way you like It is for your own use.

  Monitor SYNC / SYNC ACK / ACK to record dwMaxRcvWindowSize in the 3rd ACK packet in sequence SYN / ACK: TCP per flow only when it detects SYNC from our receiver MSTCP sending to remote server It must be created (it must not be created otherwise).

  ACK number immediately after sending an ACK response packet with TCP connection SYNC / SYNC ACK / ACK, even before receiving the first data packet (assuming this works to increment the remote server's CWND) = DwACKNumber-Offset (dwAckNumber- is the ACK number of the third ACK response packet in the TCP connection SYNC / SYNC ACK / ACK sequence), dwMaxRcvWindowSize field value, and 3 + DupNum generating dwSEQNumber field value. Continue to send 3 + DupNum DUP ACKs every WaitTimeStamp interval until the very first data packet arrives (*** Note: Step 3 is activated only after the very first data packet arrives in the program flow) Step 2 is actually always immediately active).

  2. Monitor incoming packets for FIN or RST from remote sender TCP and RST from local MSTCP → then immediately terminate the TCP flow, otherwise 16 regardless of ongoing process / loop activity, End after a total inactivity of seconds (ie no incoming / outgoing packets of any type).

  3. Procedure to check TCP flow (3 + DupNum DUP ACK transmission and / or even in the middle of a window update packet loop, ACKNo and SeqNo are always sent from the local receiver's MSTCP instantaneously latest Note that “maximum” ACKNo, “maximum”, so the smaller ACKNo of MSTCP retransmissions is ignored and should reflect the most recently transmitted “maximum” SeqNo).

  If the WaitTimeStamp milliseconds expire without receiving the next packet from our remote host to our MSTCP for any TCP flow, we will continue to quickly sequence 3 DUP ACKs + DupNum DUP ACKs one after another And advertise a window size of 0 bytes with the ACK number = latest updated dwACKNumber (recorded above) minus Offset field value and dwSEQNumber field value.

  The above 3 + DupNum DUP ACKs continue to be transmitted every 100 ms until an ACK or normal data packet is next received from the remote host again.

  Alternatively, PauseTimeStamp milliseconds now passes without receiving the next packet, whichever occurs first (Note: all pending but untransmitted parts of 3 + DupNum DUP ACKs are now Must stop immediately at the next packet or past PauseTimeStamp), then a single pure window of size = dwMaxRcvWindowSize until the next regular data packet (not a pure ACK) arrives again from the remote host Continue to repeatedly transmit size updates (dwACKNumber-OFFSET in the AckNo field, not DUP ACK, etc., and with dwSEQNumber field value) every 50 ms interval, and the next normal data After this, we loop again at the beginning of step 3 above (ie, wait for WaitTimeStamp again without receiving a packet from the remote host to “pause” the remote server ...). ...Such).

  Broadband networks (even over international backbone transport) have very very low loss rates and very very low congestion.

  The http (port 80 signature) flow must be allowed to send, for example, 1 RTT of the entire content of, for example, 64 Kbytes. Even if the SYNC / SYNC ACK / ACK phase encounters a retransmission (RFC defaults to 1 second ...) this should only encourage the use of the first 64K byte CWND. . This is because the flow along the bottleneck link is now likely to be halved. . . May be spaced (rate pacing sending one packet every R ms, so that 64 Kbytes will be sent evenly spaced over one second ...), Thus, from an elapsed interval between return ACK arrivals, such as 100 or 300 ms (corresponding return ACKs that are expected to be sent SeqNo and do not arrive after the elapsed interval ... should not use delayed acknowledgments. Can be adjusted for delayed acknowledgments when used ...) RFC detected "triggered" trigger events within RTT + (eg 100ms or 300ms) instead of 1 second (usually packet drop ...) )) Immediately → Pause unnecessarily when it is likely to be thrown away Do not send the Tsu door! . The 64K byte initial CWND should be a good choice. . . Addresses both the last mile 56K and the broadband media physical line rate.

  In addition, the minimum recorded inter-arrival ACK interval. . . From the above, the last mile medium physical line rate (56K, broadband, etc.) can be derived usefully without ambiguity.

  The receiver will send a packet with the ACKNo field = <the latest recorded maximum received SeqNo from the remote TCP (ie, for example, “ Every time a gap is detected, or when a timeout retransmission is received from a remote TCP (eg, returned ACKs or 3 + DupNum DUP ACKs transmitted, etc.). When the remote CWND is ramped up again (the remote CWND now falls back down to 1MSS or 2MSS after a time-out ...), 3 + DupNum DUP ACKs (the latest recorded recorded in the ACKNo field) Send outgoing ACKNo) May be.

  The new form for existing TCP congestion control should be:

  1. For example, using a Windows Scaling option (eg, 64K + window scale) during TCP connection negotiation, “arbitrary” large values, eg 2 ^ 30 (1 gigabyte), via a scaling factor 0-14. . . Sender TCP Window Size and Receiver TCP Window Size initialized to 0 (scale factor 0 = no need to set scaling option, see RFC 1323).

  2. The receiver TCP (or the receiver monitor software, etc.) is 4 Kbytes / 16 Kbytes / 64 Kbytes / or W1 Kbytes in the case of SYNC / SYNC ACK. . . ACK using a window size such as 4 Kbytes / 16 Kbytes / 64 Kbytes / or the receiver window size advertised when any specified number of W1 or W1 Kbyte fractions is received, W2 Kbytes, For example, increase to N2 * (4 Kbytes / 16 Kbytes / 64 Kbytes / or W1 Kbytes, etc.), where N2 is a fraction, eg, 1.5 / 2.0 / 3.5 / 5.0, or W3, W4. . . . . Wn. . . . About etc. . . . And so on (a total of 2 ^ 30, that is, less than 1 Gbyte).

  Receiver-based monitor software. . . Etc. modify the intercepted receiver MSTCP outgoing packet and advertise the receiver window size. . . Note that a new TCP congestion control method based on only the continuously advertised receiver window size can be achieved (before forwarding modified packets to the remote sender TCP).

And / or Sender TCP (or Sender monitor software, etc.) is, for example, 4 Kbytes / 16 Kbytes / 64 Kbytes / or W1 Kbytes. . . SYNC ACK using a window size such as 4K bytes / 16K bytes / 64K bytes / or the sender window size when receiving a return ACK that acknowledges any specified number of W1 or W1 Kbyte fractions Increase to W2 Kbytes, eg N2 * (4 Kbytes / 16 Kbytes / 64 Kbytes / or W1 Kbytes, etc.), where N2 is a fraction, eg 1.5 / 2.0 /, until data communication is complete 3.5 / 5.0 or the like, or W3, W4. . . . . Wn. . . . About etc. . . . (If the total is less than 2 ^ 30, that is, less than 1 Gbyte, it will probably wrap around the window size, eg as in SeqNo wraparound, or continue with a new TCP connection. ..Such).

  Sender-based monitor software. . . The receiver window size that is advertised by modifying the intercepted incoming packet from the remote receiver. . . Note that a new TCP congestion control method can be achieved based on only the advertised receiver window size that is continuously incremented (before forwarding modified packets to the sender TCP).

  It should also be noted that TCP can be symmetric and one end can be both a sender and a receiver, i.e. the above method needs to be implemented in a directional direction.

  This method allows arbitrarily finer and more flexible control / pacing of packet transmissions, while at the same time (when necessary) slow start / congestion control linear increase / 3DUP ACK fast retransmission / timeout. . . Save all other existing TCP error control / congestion control mechanisms (or provide a similar corresponding mechanism).

  For example, previous methods of transmission of 3 + DupNum DUP ACKs to ramp up CWND (or Divisional ACK technique or Optimistic SACK technique, etc.) (eg, concomitant damage to SSthresh value at initial fast retransmission) , With end-to-end TCP semantics when using Optimistic ACK, etc.), but the same objectives and more can be better achieved (eg, without the associated disadvantages, eg 3 + DupNum The advertised window size value by DUP ACKs, etc.).

  The CWND of the sender has a desired initial value of 4 Kbytes / 16 Kbytes / 64 Kbytes / or W Kbytes. . . Or the receiver can, for example, 3 + DupNum DUP ACKs or a series of such DUP ACKs or Optimistic ACK. . . Can be initially ramped up (existing RFC 2414/3390 already allows a 4K byte initial CWND value, in which case there is no need to ramp up CWND). Existing servers on the current Internet already set SSthresh to any large value (eg = TCP window size value), which should allow for a quick exponential ramp-up of the CWND value, In the absence of a large SSthresh setting, the receiver can send a large number of, for example, 3 + DupNum DUP ACKs to cause a linear ramp-up of CWND (eg 1000 DUP ACKs = 40K bytes = 320K bits, which is Send everything in less than 1 second using broadband and ramp up CWND to 1 Mbytes assuming 1 Kbyte SMSS, or CWND up to 16 Mbytes for a scaled window factor of 16 Lamp Can be For example, with a scaled window factor of 16, the minimum window size increment resolution will be 16 bytes, ie 5/8/15. . . Incrementing by bytes etc. should be impossible. With the continuously incremented advertised receiver window size method, the receiver can send the packet injection sender without the need for the sender to send packets that are evenly spaced / equally delayed between packets. Rate can be "rate limited". Note that to fully utilize this method, it may be sufficient without a window scale factor (eg, a TCP window size of, for example, 64 Kbytes without a scaling option). This is because the acceptable transmission window will “grow” with every return ACK received, ie the receiver will have knowledge of the triggering event of the network condition (and / or the latest valid SeqNo / Continually incrementing / decrementing / adjusting the advertised receiver window size using the latest effective ACKNo knowledge transmitted, etc.), so that the congested network is triggered via a “trigger event” Rwnd is detected, for example, 48/56/64 Kbytes. . . When expanding to rwnd, and thus for example 4/16/32/40 Kbytes. . . Continue the sender's effective window size which is the min (cwnd, rwnd, swnd) of the rwnd value such as when the network is detected to be not congested / not fully utilized It is because it can adjust automatically. Note that this method can be utilized by itself or in combination with any other method, such as a “pause” method. Note: The synchronized packet method can carry continuously adjusted rwnd values.

  In order to perform this method only on the receiver side without any changes at the remote server (for initial CWND, SSthresh value setting), the receiver activates this method and therefore before CWND is sufficiently large, To wait for a certain number of seconds or a certain number of RTTs or a certain number of packets to elapse / receive (without intervening sender RTO timeout and / or receiver fast retransmission request: The receiver can choose to immediately activate this method even before the sender's pending RTO timeout, etc., avoid the sender's RTO timeout, etc. Stresh with sufficiently high retransmission request (= after all packets already in flight, DUP ACKs fast retransmit a previous request CWND / 2) should be maintained. When requested or in favor of an http website access where the entire content is typically <64K bytes), the receiver can receive one or two normal data immediately after the SYNC / SYNC ACK / ACK or Immediately after the packet, CWND is ramped up immediately by Optimistic ACK (ACKNo = last valid SeqNo received + has 4/16/32 / 64K bytes ... etc., this does not affect SSthresh) At the same time, a parallel TCP connection having the same remote IP number, the same port number and the same source IP number but different designated port numbers can be established, where SYNC / SYNC ACK / One or two received immediately after ACK or received Ramps with 3 + DupNum number of DUP ACK the CWND sender optionally immediately after the normal data packet, as a result, CWND sender is now = example 4/16/32 / 64K bytes. . . (Or ramp up only when not all original TCP initial data packets have been successfully received): the original connection has successfully received all 4/16/32 / 64K bytes, for example In some cases, the second TCP connection can now be immediately terminated via an RST reset, otherwise (or at the same time as the original TCP) all missing initial 4/16/32 / 64K bytes Packets / segments can be obtained from the second TCP connection (eg, forwarded to the original TCP receiver socket by the modified software ... The modified software can, for example, make the first 4/16 if necessary. When there is an authentication packet of original TCP connection receiving / 32 / 64K bytes All packet flows in both directions, such as authentication packets, can be recorded, and the script injects exactly the same sequence into the second parallel TCP connection receiving the first 4/16/32 / 64K bytes To do). Even if CWND is initialized here to a maximum value of 64K bytes, for example, the receiver still initially sends 2/4 / 8K bytes of rwnd and increments / adjusts rwnd according to the event ( Window update packet or normal data packet), for example 2/4/8 bytes. . . Starting with, the sender injection rate can be paced.

  Note: For example, waiting for the first normal data packet received (or more ... or even immediately after receiving a SYNC ACK from the sender TCP), after which the sender's CWND is usually entered eg in the ACKNo field Ramp up with 3 + DupNum DUP ACKs set with the largest latest valid SeqNo received instead of the largest most recent valid SeqNo-1 (ie, the largest received 1 byte over the entire TCP session By using the advertised receiver window size method (along with sufficiently large window scaling at both ends), then suppress (or optionally) ACK, and then continuously increment Now, the TCP transmission rate at both ends is totally controlled and maintained. Has been successfully placed under existing TCP semantics (and using the “pause” method, the TCP at both ends can now transmit at full wire speed, subject to only “pause” congestion control, That is, CWND, TCP window size at both ends, SSthresh ..., etc., do not need to play an additional role at some point once the TCP flow is stable ... but start with a suitably smaller value, It is preferable to use a continuous incremental rwnd, for example increasing to a transmission rate allowed by the full allowable physical wire speed rate or the current rwnd size (the flow has now increased to be “stabilized”... .).

  Obviously, the sender's maximum transmission rate depends on min (swnd, cwnd, rwnd)-unacknowledged transmitted segment (or where swnd is the same initially negotiated window size throughput) Transmitted segments that have not been acknowledged reduce swnd and acknowledged segments increase swnd), and the RWND continuous increment / decrement / adjustment method Consider in rwnd update.

  Also, the remote server TCP transmission rate can now be paced by adjusting only rwnd (remote server cwnd, ssthresh, swnd is now always kept arbitrarily high or very large) Receiver-based software can dynamically pace the remote sender's transmission rate via the dynamic selection of the rwnd window update value, and thus all intercepted receivers destined for the remote server TCP. All rwnd field values in the MSTCP generated packet can be changed to the rwnd value required to pace the sender's transmission rate (this should require packet checksum recalculation changes).

  Receiver-based software / TCP (which can also be implemented as a sender-based software / TCP change) can advantageously monitor the OTT value arriving from the timestamp field, where the OTT value has a small allowable variation (eg, While remaining the same as the latest OTTest (min) (or the same as the previously known actual non-congested OTT) in the sender's OS / stack CPU processing time) Base software / TCP notes the latest maximum rwnd achieved → this is the same small allowable variation (and / or + allowed cumulative buffer delay) that the packet traversing the path in the meantime is at most the same as above For example, additional B ms) such as 0 ms / 50 ms / 100 ms ... Gives the maximum rwnd value achieved so far without encountering any fa delay or accumulated buffer delay → After that, whenever a packet is congestion dropped, the receiver-based software advantageously / optionally updates the rwnd update value ( This latest maximum recorded rwnd value as defined above can be set in the intercepted packet (modified rwnd field value) → ie congestion drop event and / or fast retransmission event. . . The receiver continues at the maintained pace of the sender's transmission rate, so that the rate is maintained at the historical highest rate achieved by the flow under uncongested traversed path conditions So that very ideal high link bandwidth utilization is maintained. Furthermore, the receiver software / TCP continuously increments rwnd unless the incoming OTT value exceeds the latest (or actual non-congested OTT) OTTest (min), ie, there is no buffer delay along the path. (Whether emulating slow start exponential rwnd increase and / or congestion avoidance linear increase) (and / or optionally decrement downward if the incoming OTT exceeds Ottest (min) In addition, however, the incoming OTT value exceeds the latest (or known actual non-congested OTT) OTTest (min), eg, as specified 10 ms / 50 ms / 100 ms, etc. (eg, packet buffering Other unmodified existing TCP flows or U that increment its rate even when it starts P due to traffic) at the time, receiver-based de software / TCP is, now, it is possible to choose to allow you to once again increment the rwnd ....

  All TCP flows along the path (conveniently assigning the smallest guaranteed part of that bandwidth to the TCP flow and some part to UDP, etc.), as described in the previous paragraph Note that in the case of modified TCP, such TCP will not necessarily cause any buffering to be required at all → Almost completely congested / unbuffered routes are always maintained . To ensure fair sharing that allows the newly established modified TCP to grow when the existing modified TCP has already achieved together the full utilization of the full bandwidth of the traversed link. In addition, the newly established TCP increases its transmission rate or rwnd or cwnd to the point where it does not exceed the 100 ms extra delay of eg OTTest (min) or RTTest (min) or their known actual value. When all modified TCPs experience an extra delay of, for example,> 100 ms, all have a certain ratio, eg 10% / 15% / 25%. . . Should reduce its transmission rate or rwnd or cwnd by, etc. (this favors an existing established flow, but also allows a new established TCP to begin achieving its transmission rate increase. ). Note that there should be no congestion drop as long as all nodes traversed have, for example, more than 100 ms equivalent buffer. Another scheme is the continuous transmission rate or rwnd or cwnd until the beginning of the packet begins to be buffered (indicated by the extra delay of the latest OTT or RTT OTTtest (min) or RTTest (min)). . . . Such that the transmission rate or rwnd or cwnd is decremented backward by one step (thus before or after the 100% utilization level). Oscillating forward increment and backward decrement at).

  Note also that the various schemes described above can be easily implemented as sender-based TCP as well.

  Simply, for example, a congestion drop event (at which time the modified TCP is the maximum achieved transmission rate or the rwnd or cwnd size or percentage thereof under the overall non-congested condition, or simply the congestion drop Allowing the transmission rate or rwnd or cwnd to increase to the current transmission rate when it occurs or back to a percentage of rwnd or cwnd size, etc.) allows good coexistence with current RFC standard TCP flows To. When the “pause” method is incorporated, the “pause” interval is the latest OTT value or RTT value just prior to the detected congestion drop and OTTest (min) or RTTest (min) or a known non-congested actual It can also be derived from the OTT value or the RTT value: for example, if the latest OTT just before the congestion drop event is 700 ms and the OTTTest (min) is 200 ms, now all nodes are buffered To completely clear the packet, the “required” pause interval can be set, for example, 500 ms (700 ms-200 ms), or more, for example 600 ms or less, for example even 400 ms.

Among the possibilities, an example receiver-based implementation (note that sender-based should be similar but simpler) is simply that the receiver requires a window scale option. Yes, for example, scaling to a maximum value of 256 Mbytes (the maximum possible scaling is to shift 1 gigabyte, ie 2 ^ 14 * 64 Kbytes, or the normal unscaled 16-bit window size 14 times to the left, where , The maximum value of 256 Mbytes left shifts the window scale factor of 12, ie 12 ^ 12 * 64 Kbytes or the normal unscaled 16 bit window size: Google Search terminology “window scale size”, http: //rdweb.cns .V http://support.microsoft.com/default.aspx?scid=kb;en-us;1999:// , http: // www . training / netperf-talk / 0207.html, http://www.ncsa.uiuc.edu/People/vwelch/net_perf/tcp_windo ws.html, http://www.monkey.org/openbsd/archive/bugs/0007 /msg00022.html, http://www.freesoft.org/CIE/RFC/1072/4.ht , Http://www.freesoft.org/CIE/RFC/1323/5.htm, http://www.networksorcery.com/enp/protocol/tcp/option003.htm, http://www.ehsco.com / Reading / 199990628 ncwl.html , Google Group Search term "window scale size", http://rdweb.cns.vt.edu/public/notes/win2k-tmpip ) (4K bytes happens to correspond to the initial CWND value of the experimental RFC), giving the minimum possible resolution.

  1. The remote server can select the scaled sender window size correspondingly, but it can simply allow the receiver to choose to scale but not to scale its own sender window size. Yes: this is not very important (such negotiated window size (s) is too large for the last mile and / or first mile physical bandwidth, eg 56K / 500 Kbs ...) Even).

  Note: If the sender performs a window scaling factor similar to the receiver, this simply sets eg the receiver PC's TCPWindowSize registry value eg 1 and eg 2 ^ 14 eg scale factor (the minimum window size resolution is Can now enable a very simple and ready use of this method without all the new software or modified TCP needed, so The sender's effective transmission window is always limited to about 4K bytes (2 TCPWindowSize registry values and 14 scaled), since the receiver should now always only set at most 4K bytes to its rwnd. Receiver called factor With C settings registry settings or application socket buffer, which gives a resolution of approximately 16K bytes * 2 i.e. 32K bytes).

  2. The receiver modifies all intercepted outgoing packets as needed, and each of their receiver window size fields always has an appropriate upper ceiling value, eg, 16K bytes for 56K receiver last mile dialup, or For example, 96 Kbytes for the last mile DSL of a 500 kbps receiver. . . Guarantee that it does not exceed.

  [The simple, very elegant arrangement here should now have guaranteed an increase in CWND for ultra-fast exponential senders throughout the TCP session, for example to always reach CWND of 64K. Does not require, for example, about 64 RTT times, but only requires at most 6 RTT times (note that the sender's initial SS Threshold is set to a very large and scaled receiver window size). However, the sender's maximum effective transmission rate should always be limited to the value of the modified receiver's window size upper ceiling received → the sender's transmission rate is always the receiver The window size of the sender does not exceed what is allowed by the upper ceiling, `` Windowing window '' size and “self-clocking” characteristics via back ACKs (the back ACK rate is usually the minimum bottleneck link available bandwidth, which is usually in the first mile or last mile media link) Note that this is reflected). The beginning of the buffer delay along the path should slow down the sender's BDP throughput, but the limited congestion packet drop causes the receiver to request a 3DUP ACK fast retransmission and is now halved for this sender. The CWND and SSthresh values that are most likely will continue to remain much larger than the receiver's window size upper ceiling value at all times, but sustained congestion packet drops time out RTO retransmissions to the sender Let this sender's CWND now slow start again, for example at 4MSS, but it should also quickly increase exponentially → the sender's CWND of all such TCP flows is now Control up to the upper ceiling of the receiver window size It is is, but it can be seen that is maintained in the near almost all the time. . . .

  3. Optionally, the receiver can pace the injection rate of packets into the sender's network by slowly increasing the receiver window size field of outgoing packets, for example, immediately after TCP establishment, the receiver can start from 4K bytes. Start, then 8K bytes, then 12K bytes. . . Next, a series of, for example, 16 pure window update packets can be transmitted at equal intervals at 64 Kbytes, for example, every 62.5 ms, for example every second (immediately, an upper ceiling window of 64 Kbytes). Instead of advertising the size, this advertisement should cause a packet burst), thus ensuring that there are no sudden large packet bursts from the sender (the back ACK will be sent during this series of window size updates) Note that if present, the possible packet injection rate should be increased, but the receiver can optionally take this into account and reduce the window update size value). The receiver can optionally change the receiver window size field value of the ongoing packet whenever appropriate. Similarly, such a window size update / change is probably the latest outgoing transmitted ACK value. . . Can be implemented at any desired form of increment / decrement / adjustment at any time. This can be useful for fetching http website content in the fastest optimal form immediately after TCP connection establishment (ie, for later transmission at the receiver's possible last mile physical maximum line rate, for example). Sender pacing: Note that it may be unproductive to have the sender immediately burst all of the 64K byte content, for example, at 1 RTT ...).

  4). Further, optionally, this can be done with the “pause” method and / or the “inter-packet arrival” method and / or the various methods described in the previous paragraph. . . And so on. For example, if the non-congested RTT / OTT here is, for example, 50 ms, the “pause” method will now use the non-congested RTT / OTT between the two ends (or the latest estimated non-congested RTT / OTT). ) A timeout period that is the sum of the value and the buffer delay of 200 ms, for example, and a “pause-interval” for a timeout of 150 ms, for example, can be specified. The bandwidth of the bottleneck link here is always constant. 100% can be used. This is because the “pause” method here strives to keep the buffer occupancy of the cumulative traversed path occupied within one buffer at any time, ie, the bottleneck link is always 100 % Is available.

  For this reason, it should be noted that the sender's CWND mechanism herein is redundant with respect to requirements in achieving congestion control objectives in several stages (CWND during congestion trigger events, avoiding RTO timeout events). Unless other component methods such as inter-packet arrival method plus 3 + DupNum DUP ACK ... to quickly increase the size are not incorporated). In this case, therefore, CWND continues to play only a partial role of network available bandwidth probing in the very early stages of exponential and / or linear growth to achieve very large values (connection The maximum transmission rate at any time, for example, the receiver advertises in a scaled and shifted format rather than advertising eg a 64K rwnd value, eg to a relatively very small rwnd value) TCP now advertises only 4 showing the same rwnd value as 4 left shifted by 12 positions, ie 64K, when the maximum scaled factor 14 is utilized: both ends are now very much Allow / negotiate large maximum scaled window size However, the receiver TCP can only advertise its normal physical current latest maximum available receiver window size, for example if its physical maximum possible receive window buffer resource is 16K. Assuming that a maximum scaled factor of 14 is used, the advertised receive window size field in all packets generated by the receiver TCP will always only indicate the maximum possible value of 1. Then, even if the CWND value and / or SSthrsh value during 3DUP ACK fast retransmission / recovery is halved, the halved CWND value and / or SSthrsh The value remains very large compared to rwnd: the network is non-radiative When remaining congested, the sender happily transmits at the maximum rate limited only by the available segments / bytes within the sliding window (depending on the self-clocking characteristics of the returning ACK) and / or rwnd or cwnd size During a 3DUP ACK fast retransmission request, the sender's maximum transmission rate is now limited only by the available segments / bytes in the sliding window (this usable segment / byte in the sliding window is , Now appropriately reduced by the ratio / number of transmitted flight packets that have not yet been acknowledged, where even if both CWND and SSThresh are halved, the halved CWND and SStress are Still RWND or S Since this is much larger than ND, this CWND and SStresh have no effect at all), so in effect, the transmission rate is now reduced appropriately proportionally and on RTO timeout (usually 1 second) After the RFC minimum lower ceiling time period), the sender transmission rate, ie the value governed by one or more SMSS restart CWNDs, is now reduced to the minimum value, but in fact the same as before the RTO timeout. The transmission rate can almost always be retained, because the sender here usually has transmitted a very large part or all of the segment / byte for the valid window before the RTO timeout. Thus, successive immediate transmissions of multiple RTO timeouts have not yet been acknowledged The size / number of ratios of such “congestion drop” packets in all non-acknowledged segments transmitted within the effective sliding window, followed quickly and continuously caused by the transmitted segment / packet sequence is ( Doesn't reduce the sender's transmission rate after, for example, a 1 second RTO timeout event, even if everything is congestion dropped), but the sender stops all transmissions, for example during a 1 second period before the RTO timeout → The buffered packets of all intervening nodes should be equivalent to this / these specific modified per-TCP flow buffered packets, for example an amount equivalent to 1 second (or others) The equivalent amount of buffered packets) For example, an amount equivalent to 1 second far exceeds the normal buffer equivalent capacity of a node of 200 ms to 500 ms, so it is equivalent to 1 second of buffered packets of most other unchanged existing TCP flows. It is very likely that the amount (or equivalent amount of buffered packets of other flows) will be cleared, and some other TCP flows will later change to a minimum It can time out longer than 1 second (if its RTT is unusual and very long), helping to ensure the overall clearing of buffered packets for all traversed nodes (all (Note that this may be RTO timed out, although some may be slightly later) [Note: This is a large 1 second Have "pause" interval and is synonymous].

  This method, in its simplest form, only requires the user to set a local PC TCP registry parameter to take advantage of a large window scale factor, such as a scale factor of 12, but the 16 bit normal The TCPWindowSize value can be set as small or large as necessary, eg 1 to 64 Kbytes: 12 user PC scale factors, ie 256 Mbytes maximum possible scaled window size value and only 1 user PC Using the TCPWindowSize value and the negotiated scale factor of eg 12 remote servers and the remote server TCPWindowSize of eg 64 Kbytes, the remote server maximum transmission rate is However, it does not exceed the user PC's scaled window size of 4K bytes (1 * 2 ^ 12) per RTT (if there is intermediate software, the intermediate software does not intercept outgoing packets from the user PC, and 4K (Assuming that the rwnd field value is not changed to be greater than bytes). Note that the remote server's Ssthresh value is usually initialized to be the same as the rwnd value negotiated during TCP connection establishment. In order to implement this method at the sender, the remote server fixes the window scale option for TCP connection negotiation, for example, fixing it to “infinity” so that the TCP stack of the remote server is arbitrarily very large. Utilize (and / or fix its CWND value to its maximum achieved increased throughput, ie CWND can be continuously incremented from the initial RFC value of, for example, 1 SMSS, but never decremented) You just need that.

  Utilizing the modified TCP increases throughput, for example a data storage site backup application on a dedicated line / DSL. . . Thus, attention has been focused on reducing the ftp transfer completion time of large files. This is because when using existing TCP, the sender always increases its transmission rate at all times, that is, CWND increases monotonically until packets are discarded due to congestion. Sender TCP aggressively reduces its transmission rate, i.e. resets CWND to e.g. 1 SMSS and immediately before the RTO timeout (or just before the 3DUP ACK fast retransmission request, at this time the sender's transmission rate Start a very long and slow climb up back to the achieved transmission rate (ie CWND is halved) or CWND size achieved. Assuming that the TCP flow does not have the 3DUP ACK fast retransmission mechanism enabled, the transmission rate or throughput or CWND graph for the flow here is the known “sawtooth” pattern slow linear climbing up to the maximum repeated and then It is immediately obvious that a sudden drop back to near “0” of the link, ie, up to half of the physical usable bandwidth of the link is wasted and not used, but the modified TCP flow is almost It should show the transmission rate or throughput or CWND graph of the physical available bandwidth utilization of a constant 100% link, ie up to twice the throughput of an unmodified TCP flow / should transfer transfer completion time in half. With the 3DUP ACK fast retransmission mechanism enabled, the TCP flow graph should show a mix of half of the previous transmission rate level and a sudden drop near “0”, so the modified TCP The flow should show somewhere between 33% and 100% more throughput compared to the unmodified TCP flow → instantaneously double the “apparent” physical bandwidth of the link Probably enabled, where links are leased lines / intercontinental submarine optical cables / satellite / wireless. . . And so on.

To reiterate, the “large sender scaled window size” method in the preceding paragraph above (in the case where a connection at either end does not actually have the actual need for such a large scale window size). Can be used immediately by PC users, even without requiring any changes to software or existing standard TCP: users can manually set their PC's TCP system parameters, For large scaled sender window sizes (eg TCPWindowSize and / or maxglobalTCPWindowSize, Window 2000, setting TCPWindowSize greater than 64K bytes should automatically enable the window scale factor) TCP 1323 opt 1 or 3 (1 enables the window scale factor but no TimeStamp option, 3 with the TimeStamp option) Enables the Window Scale Factor value between 1 and 2 ^ 14 Can do. The receiver TCP must allow the sender TCP to negotiate the window scale option, but the maximum received window size of the receiver TCP itself is the “bottleneck link bandwidth capacity” of the path traversed by the IP packet. It should preferably be kept relatively small in order to only be fully available (the bottleneck link here is usually the sender's first mile medium, eg DSL or receiver first mile, eg leased line) For example, the non-congested RTT between the two ends is, for example, 100 ms, and remains totally constant at this, for example, 100 ms value, and the bandwidth capacity of the bottleneck link is 2 mbs. Assuming that The maximum window size is relatively small and must be kept / set, for example, to only 25.6 Kbytes (this ensures that the sender TCP CWND quickly achieves the maximum window size of the receiver, for example 25.6 Kbytes). Even if it is fully maintained at a very large value allowed by this very large scaled maximum window size value (which causes a fast retransmission) (Sender guarantees that packet loss / destruction events now almost never drop to the halved CWND size and halved Stress value of the sender TCP almost below the maximum window size of the receiver, eg 25.6 Kbytes) TCP "effective window size" Yes However, it is guaranteed that it will not exceed 25.6 Kbytes and therefore will not always transmit at a rate higher than 2 mbs, very rarely after a packet loss event that causes an RTO timeout retransmission where the sender CWND size is reset to eg 1 SMSS. Sender TCP's CWND re-achieves and exceeds the maximum window size of the receiver very quickly in only 5 * eg 100ms RTT, ie only 500ms, eg 25.6K bytes). The transmission rate graph / instantaneous throughput rate graph here (which can be seen using the Ethereal's IO-Graphs traffic display analysis facility http://ethereal.com ) is a link bandwidth closer to a nearly constant 100% Should show utilization, ie the graph here is compared to the existing standard TCP which shows a “sawtooth” shape with a flat in the sawtooth valley farther from the 100% link utilization level, almost constant. Thus, it should resemble a “square wave signal shape” with an uppermost flat plate closer to the 100% link utilization level.

  However, in the real public Internet, the RTT between the two ends is only orders of magnitude over time (e.g., unless the end-to-end RTT is guaranteed by the carrier's IP transit service level contract guaranteed RTT / bandwidth). (For example, receiver maximum window size). . . That “throttling” of the sender's transmission rate to the bottleneck link bandwidth capacity via, etc. is such that when such RTT on the public Internet becomes longer, digit throughput and / or “ It should suffer "goodput" degradation: setting a much larger value for the receiver's maximum window size here is much more able to handle such a long public Internet RTT scenario For example, if the maximum window size of the receiver is now set, eg, 25.6 Kbytes before 8 *, for example, end-to-end throughput and / or “goodput” may be Assuming that it should not exceed 8 times the non-congested RTT during It can be maintained in the vicinity of the bandwidth capacity of Runekku link.

  When the CWND of the sender TCP is stable and not increasing (for example, when the CWND has reached the maximum sender window size value), the amount that the sender TCP can transmit (TCP sliding window) ACK self-clocking function, i.e. according to the rate of incoming back ACKs, the maximum rate of this back ACK is still the bottleneck link bandwidth capacity of the traversed path, i.e. how fast from the sender Limited to the ability to transfer data along the bottleneck link, which is approximately equal to the bottleneck bandwidth in bytes per second (for example, ignoring the 40 byte overhead required for non-data IP packet headers) Please note that. As the sender TCP's CWND continues to increment exponentially in the “slow start” phase, the CWND actually increments during each successive RTT according to the number of ACKs returned (not necessarily exponential during each successive RTT). (Rather than doubling functionally), ie TCP's current CWND is 8K bytes, 8K bytes of data segment (allowed by maximum sender size and maximum window size, with enough returned ACK) CWND assumes a “slow start” if the next RTT returns only 6 and 2 are discarded (assuming enough “valid windows” ...) It should now only increment to 14K bytes (rather than being doubled to 16K bytes). Congestion is now transferred by the bottleneck link bandwidth capacity to the transmission rate, because the current incremented CWND size (and thus the effective window currently increased rather than being caused by an increase in the number of received back ACKs). As long as it remains below a value that should exceed what it can, it does not occur. However, if the transmission rate is now greater than the transmission rate of the bottleneck link bandwidth capacity, some transmitted packets now begin to be buffered on the bottleneck link (Internet nodes are usually around It has a buffer capacity equivalent to 200-400 ms). When the sender's transmission rate exactly matches the transmission rate of the bandwidth capacity of the bottleneck link, when CWND is now "doubled" in size at the next RTT, the RTT here will be around 100ms Assuming that it remains, at this next RTT, a packet equivalent to 100 ms exceeding this extra bandwidth capacity needs to be buffered at the bottleneck link node. The rate of returning ACKs in consecutive RTTs now remains at or around the maximum bottleneck link bandwidth capacity (ie, the bottleneck link continues to transfer data at 100% link bandwidth utilization). Assuming the sender's CWND is continuous by an amount equal to the bandwidth capacity of the bottleneck link at each successive RTT, for example until the 4th consecutive RTT, causing the bottleneck node to run out of buffers and thus discard packets. Each successive RTT is incremented with the previous RTT due to a continuous eg 100 ms equivalent amount of extra buffered packet traffic introduced by the incremented CWND (or incremented valid window). Slightly longer. Next, when the sender receives three DUP ACKs from the receiver TCP, it is likely to retransmit the discarded packet fast, in which case the CWND and SSthresh values are now halved. And still remain much larger than the relatively small receiver maximum window size value → almost constant, so the sender TCP will then continue to transmit at the same previous rate that is not reduced by these packet drop events Since the ACK returns at a rate equal to the bandwidth capacity of the bottleneck link, the sender's transmission rate now assumes that the bottleneck link bandwidth capacity (which is less than or equal to the receiver's maximum window size). ) Should continue to be the exact maximum rate equal to. If the sender has not yet been taken care of by the receiver's 3DUP ACK fast retransmission request, it can also perform RTO timeout retransmission of discarded packets only after the existing RFC default minimum time period of a minimum of 1 second. These are very much rarer: in that case, the sender's CWND still exponentially very quickly in just 2-3 RTTs to re-achieve / exceed the relatively small receiver maximum window size value Note that it should increase functionally (assisted by an “arbitrary” large Ssthresh value). The sender's CWND here increases "exponentially" to a very large value (even if it is "maintained") even though periodic fast retransmissions halve the CWND and Stress values. There should be a trend towards Ssthresh values). If the sender's TCP CWND achieves / exceeds the receiver's maximum window size, then that CWND will be primarily the received share of the self-clocking rate of the returning ACK, and its total rate will be At most, it is equal to the bandwidth capacity of the bottleneck link at any point in time, which will now define the sender TCP transmission rate. The TCP response variation at the other end when generating the response ACK may reduce the rate of the returning ACK to less than the rate of the bottleneck link bandwidth capacity, and the buffer at the intervening nodes along the traversed path Delay (longer RTT). . . May reduce the overall return ACK rate for all TCP flows traversing the bottleneck link to less than / less than 100% of the bottleneck link bandwidth capacity (thus, The receiver's maximum window size is exactly the minimum required to fully utilize 100% of the bottleneck link's bandwidth capacity assuming the same non-congested RTT throughout the TCP session, enough to compensate for variations. Setting it to be larger than the size should allow 100% bottleneck link bandwidth utilization at all times, regardless of such variations).

  Here, the sender's maximum window size value and CWND value can be arbitrarily increased at any time (so maintained and helped by an “arbitrary” large Ssthresh value) and a relatively small receiver maximum window size value. Using the above-mentioned "unnecessary but intentional" large scaled sender window size and the relatively small "receiver maximum window method" in this specification, the end-to-end TCP connection uses the bandwidth of the bottleneck link. It can be seen that there is a trend towards a stabilized transmission rate equal to the width capacity, ie the transmission rate or throughput graph here should show a link utilization level “square waveform” close to 100%.

  Conventional file transfer technologies, such as FTP, dramatically reduce data rates in response to all packet losses and cannot maintain long-term throughput with the capacity of high speed links. For example, a single FTP file transfer over an OC-3 link (155 Mbps) in a metropolitan area network is stable at 22 Mbps assuming a packet loss percentage of 0.1% and a latency of 10 ms.

We now send the sender's local intercept software to 3 + DupNum DUP ACKs (ACKNo = latest received ACK number from receiver TCP and / or SeqNo = receiver TCP for local MSTCP preempt timeout transmission rate reduction. ACK packet-return interval of latest arriving ACK received at sender TCP from receiver TCP> e.g. 300 ms (not necessarily congestion drop, physical error) to generate the latest received SeqNo field Can also be caused by: we can add a simple code just to check (catch both here). It is well known that even 0.1% physical error corruption (not congestion) in transmitted packets should strictly limit throughput by 80%, http: // www. asperasoft. com / technology-faspvftp. See html # continental .

Overview:
1. It only needs to incorporate an incoming / outgoing packet intercept core and a TCB for each TCP flow.

  2. Record the latest “maximum” SeqNo field “lastsentSeqNo” sent remotely from the local MSTCP.

  3. The ACKNo field “lastrcvACKNo” of the latest “largest” incoming packet received from the remote (and the SeqNo of the packet, ie “lastrcvSeqNo”) and the received time “lastpktrcvtime”, and a copy of this complete packet “lastrcvpkkt” And record.

4). IF current time-lastpktrcvtime> for example 300 ms AND lastsentSeqNo + 1> lastrcvACKNo
THEN send 3 “lastrcvpkkt” (simpler, no need to calculate checksum of the generated packet: duplicate SeqNo / duplicate data ... etc., 3DUP ACK if present in lastrcvpkkt It is only ignored by local MSTCP while causing fast retransmissions).

5. During software initialization, edit the TCP registry (and / or optionally the buffer size per socket of the individual application itself), all new TCP has a large window scale factor of 14 and TCP window size of 64K (ie up to 1 gigabyte) ), Preferably SACK enabled, preferably without Delay-ACK [Reference: Google Search term “set socket buffer oversize large window size” (or similar related terms), www. psc. edu / networking / perf_tune. html , public. boulder. ibm. com / infocenter / prises / topic / com. ibm. aix. doc / aixbman / prftungd / 2365a83. html, www. dslnuts. com / 2kxp. shml , http: // www. ces. net / doc / 2003 / research / qos. html , forum. java. sun. com / thread. jspa? threadID = 596030 & messageID = 3165552, netlab. caltech. edu / FAST / meetings / 2002july / relatedWork. ppt, www. ncne. org / research / tcp / debuging / firstpackets. html ).

  Thus, this fully meets the requirements of data storage applications.

  Note: TCP per flow with a large window scale factor and large window size negotiated at both ends, within 10 RTT, eg 2.5 seconds, CWND value up to MSS, eg 1024 * 1500 bytes, ie 1.5 Mbytes Increases very quickly. Setting either CWND halving and SSThresh to CWND / 2 on any fast retransmission request, whether software generated (eg preempting RTO timeout) or remotely, will result in an “effective window”. At any time after SYNC / SYNC ACK / ACK without having any effect of reducing, the “valid window” is always one of the following:

  1. Always limited to the advertised receive window size of the receiver: The receiver typically has, for example, 16K bytes, so in every subsequent packet, the receiver will receive a receive window size of "1" (14 position scale shift) ) = 16K bytes) → The local sender's transmission rate will always be the rate for this "16K" receiver's advertised window size, which is very effective due to the ACK-specific self-clocking characteristics. “Rate paced” (as we have become very conscious in the past few days). Note: CWND and sender window size can be arbitrarily increased and play no further role in congestion control (if CWND achieves a size much larger than the receiver's maximum window size !!! Its ACK self-clocking feature that adjusts the available transmission rate to the available bottleneck link bandwidth, but of course, the receiver continues to dynamically adjust the advertised receiver window size to control the sender's transmission rate Or intercept software residing at the end of the sender, optionally, dynamically changing the receiver window size of incoming packets to be similar to the MSTCP transmission rate / "effective window" to send Working control Rukoto can).

Or 2. We deliberately over-set the arbitrarily large scaled window size value (or simply a large unscaled 64K, scaled 256K ..., etc. value) to the maximum window size of both senders to be seated. , So that the maximum window size of the receiver is four times larger than what is actually required / required during the negotiation (for example, 64K, 256K. Etc.) so that the sender's CWND and SSthresh (usually set to the same as the negotiated receiver maximum window size value) almost always result in frequent fast retransmission halving. Regardless, very much larger values (re A very efficient 100% bottleneck link “utility square waveform” that is much larger than the advertised receiver window size constrained by the actual system resources of the network. Guarantee: This is guaranteed by the maximum possible rate of back ACK self-clocking that arrives back only at the bottleneck link line rate. Because both CWND and sender window size can now be sent at a rate fast enough to take advantage of 100% of the bottleneck link bandwidth capacity that is now always traversed almost constant. Because it is many orders of magnitude larger than the specific sender window size value required to guarantee (this is related to the well-known bandwidth delay product or well-known RTT * window size equation), and After CWND quickly achieves a size larger than the receiver's negotiated window size value (eg, 64K, 256K, etc. above), the sender TCP herein will then increase the window size during successive RTTs. The maximum negotiated window size of the receiver via (example above Does not increment the actual “valid window” beyond 64K, 256K, etc., and therefore only clocks out / sends out further packets when a subsequent ACK stream is received. (The maximum rate of returning ACKs is always constrained here to be within the bandwidth capacity of the bottleneck link).

  Note: In both cases 1 and 2 above, the intercept software (or TCP source code) sets the receiver window size field value in the incoming packet from the remote receiver to any required smaller maximum value (eg, the latest Dynamically derived from recorded minimum inter-ACK interval and non-congested RTT / OTT values or estimates, etc., or identified from previous knowledge of the bandwidth capacity of the bottleneck link that the user is traversed Can be specified), so that the effective window size of the sender TCP is the size required to match the bandwidth capacity of the bottleneck link being traversed. Can guarantee that the level will never be exceeded → now it is a dynamic receiver There is no need to rely on the receiver's system resource constraints to limit the advertised window size field value, and the maximum window size value for both the sender and receiver can be the same, arbitrarily very large scaled window Both can be negotiated together to be a size value.

  Note: We may further guarantee / need that the sender's CWND is certainly increased from the beginning to a sufficiently large or very large value when establishing the ftp TCP data transfer channel, This immediate packet drop at the very initial stage may cause the sender's SSThreshold to set half of the current initial very small CWND value: Can be achieved by intercept software that stores the transmitted data packets, for example performing an actual retransmission of any of the 10 unreceived packets to the remote receiver (ie not received at the remote receiver TCP) Incoming during this time to detect missing packets Check back ACKNo and / or discard / modify such arriving packets back to local MSTCP to prevent local MSTCP from resetting this value to half of the current initial very small CWND value at this time Do not forward).

  Note: This is much simpler if the sender's TCP source code is available for direct modification: for example, here the Ssthresh value is now “permanently set to any very large value. The maximum sender window size of TCP to be fixed and / or transmitted is now fixed “permanently” to any very large value. . . It is only necessary to change the source code so that it becomes (and there are many ways to achieve this goal ...). Also, all methods / techniques can be correspondingly modified to act as receiver-based control (rather than sender-based control).

  Note: In addition, in the following very basic form, the above “square waveform” technique should be immediately available manually without any software required.

1. 1. Manually set the registry of the two PCs accordingly for large window scale, large window, SACK, no Delay ACK Large FTP between these two PCs
3. The FTP transmission rate / throughput graph here must show a “bottleneck link utilization level square waveform close to a constant 100%”.

  We have also added a minimum inter-packet delay that sends a normal data packet at the latest observed “recorded” back-inter-ACK interval observed (for example, bytes per second (must accommodate bottleneck link capacity). This value can be derived / updated only from the previous specified previous time interval, eg, derived / updated every 300 ms, for example), if necessary Packets may be buffered → There is no “burst buffering” at the router that may contribute to unnecessary transient congestion packet drops rather than actual congestion.

  This intercept software can cause congestion drop from CWND successive RTT exponential increments (exponentially incremented CWND remains below the advertised window size of the receiver, eg While allowing 100% of the bottleneck link bandwidth and doubling the transmission rate without regard to ACK self-clocking, some users may use the actual physical receive buffer size system resources You can even set it to be really big).

  The existing “pause” technique, ie “pause” or specified for the latest minimum “recorded” inter-back ACK interval (corresponding to the capacity of the bottleneck link) for all back ACKs outside the “timeout” E.g. if the interval expires without receiving a new next incoming back ACK since the previous back ACK (eg 1.8 * latest minimum recorded inter-back ACK interval) It must incorporate not simply forwarding the next pending intercepted packet forward to the remote receiver TCP for a period equal to the first recorded inter-back ACK interval, ie the minimum inter-back ACK interval → , Sender TCP, the first transmission ACK is 1.8 * Before the “pause” triggered by returning outside the returned inter-ACK interval, eg 90 ms, each with at most two packets (each with a rate-paced minimum minimum return ACK of eg 50 ms) → the software is achieved by itself, which does not cause congestion drops + incremental deployment on the external Internet + TCP friendly + even when other TCP causes packet drops Keep non-congestion level transmission rate throughput (no fluctuation). Various information about such buffered packets, such as intercepted packets waiting for transfer to the remote receiver TCP and / or the time of reception at the buffer. . . To the local MSTCP when the waiting time in the buffer queue of a particular buffered packet, for example, reaches the default minimum RTO time period of a standard RFC of 1 second, for example. A 3DUP ACK fast resend request (to preempt the RTO timeout in local MSTCP) and any newer “fast resend” to this particular buffered packet in the queue Replacing with a packet may / can be further required.

  Note: Existing standard RFC sliding window / AIMD mechanism. . . And / or an existing standard RFC sliding window / AIMD mechanism. . . An alternative TCP congestion control mechanism that works in parallel as intercept software (and / or direct TCP source code changes), etc., together with the “transmission rate pause” technique, the inter-arrival ACK interval “transmission rate pacing” of the previous paragraph above. (E.g., to pause / skip packet transfer to the remote receiver when the next returning ACK arrives outside the specified time period since the previous ACK arrived) E.g., the latest value of the return inter-ACK interval between the latest consecutive packets and / or the actual RTT value or OTT value of a particular packet (the beginning of congestion buffering along the traversed path, or Adjust very well to show that there is no) Must either increment / decrease the STCP packet generation rate (enabled for transfer at a faster incremental rate / lower decrement rate) or an existing standard RFC TCP's very own existing AIMD function must be used in parallel (and / or buffering of packets waiting to be forwarded to the remote receiver, and / or RTO timeout of old queued packets) Replacing old version packets queued in buffer to provide 3DUP ACK fast retransmission request generation to local MSTCP to preempt and / or inter-ACK interval "send / pause rate pacing" technique Latest new retransmission packet and / or event Trst reception time / transmission time information and / or for each packet RTT / OTT monitoring ... with like). In a periodic specified time period, the above schema will show that the latest best estimate of the bandwidth capacity of the bottleneck link of the traversed path is the latest recorded minimum returned ACK interval that will arrive later. In order to ensure that the values are continuously updated, two or a few packets are immediately forwarded one after another to the remote receiver in a very quick sequence possible with the bandwidth of the adjacent first mile link. Can be guaranteed to be available for forwarding (eg, wait until two or a few packets are available before forwarding them forward together, etc.) Neck link bandwidth capacity can be further derived at a finer level of bytes per second rather than packets of a certain size, and transmission rate Adapting the sourcing technique and / or transmission rate pause technique to know the actual size of the pending packet size transmitted forward and to take advantage of this derived common finer granularity of bytes per second Note that you can The schema here can utilize its own devised algorithm to increment / decrease the paced transmission rate, which is different from the existing RFC sliding window congestion avoidance mechanism. The transmission rate here should show a bottleneck link utilization level "square waveform" close to the same constant 100%, and always the transmission rate is a bottleneck link utilization level close to 100%. It oscillates in a very narrow band before and after.

Note: The local intercept software here temporarily prevents local MSTCP from generating / sending new packets, such as when the number of packets in the intercept software's forwarding buffer packet queue exceeds a certain number or total size. Generate a window size update packet to “stop” (or reduce the local MSTCP packet transmission rate) or set the receiver window size field value in the incoming packet from the remote receiver TCP to the local MSTCP as needed, eg It can be changed to “0” or a very small value. This prevents an excessively large packet queue increase that may cause the final RTO timeout in local MSTCP.
Quantification of large FTP transfer improvements: simplified.

  In order to achieve a minimum 50% throughput improvement (eg, there should be a much larger improvement from other factors, from 1 MBS to 1.5 MBS), constant periodic packet loss (and fast retransmission) is: It occurs at the very moment when the sender transmission rate reaches the maximum line rate.

  (1) Assuming a constant packet loss rate every 1000th and a RTT of 200ms, the maximum window size is to transmit everything and throttle the rate to 1000 packets per second. In addition, it is necessary to have 200 packets (300 kbytes).

  SSthresh values generally wander around 1/2 * maximum window size (100 packets or 300 kbytes) due to continuous fast retransmission halving, because CWND re-achieves the maximum bandwidth transmission rate Must be incremented by 100 packets (150 kbytes) → 100 RTT is required (20 seconds).

  The bandwidth of the minimum link needs to be 600 kb / s in order to transmit 1000 packets in 20 seconds (1000 * 1500 * 8/20).

  (2) Assuming a constant packet loss rate every 100th and a RTT of 200ms, the maximum window size is to transmit everything and throttle the rate to 1000 packets per second. And 20 packets (30 kbytes).

  SSthresh values generally wander around 1/2 * maximum window size (10 packets or 15 kbytes) due to continuous fast retransmission halving, because CWND re-achieves the maximum bandwidth transmission rate Needs to be incremented by 10 packets (15 kbytes) → 10 RTT is required (2 seconds).

  The bandwidth of the minimum link needs to be 600 kb / s to transmit 100 packets in 2 seconds (100 * 1500 * 8/2).

  Such “square waveform” TCP should be TCP friendly, and all TCP flows traversing the bottleneck link are such “square waveform” flows or such “square waveform” flows and existing standards. When composed of a mixture with RFC TCP flows, the total rate / total number of ACKs back to all such flows / all such flows is still the bottleneck link bandwidth of the traversed path. It should be limited to no more than what corresponds to the width capacity-> such "square wave" TCP flows are incrementally deployed on the external Internet, and other existing standard RFC TCP flows and "Sawtooth" effect of a mixture of flows and / or public internet congestion packet drop and / or BE It can maintain / hold its achieved transmission rate despite packet drops caused by packet corruption (bit error rate), while at the same time all such “square wave” TCP flows and / or other Can remain TCP friendly to existing standard RFC TCP flows (Note: New TCP flows almost always begin to increase their transmission rate using the capacity of the network node buffer in any case) be able to).

  With modified TCP, when link traffic begins to be buffered, the corresponding echoed RTT is now the specified multiplicand * specific source-destination non-congested RTT value (specific The software can now stop sending per-TCP flows during the specified “pause” interval, which usually exceeds the packet size (usually determined by the system MTU size or MSS size) → This ensures that all traversed node buffers are immediately cleared of all buffered packets (or equivalents) of this per-TCP flow during this “pause” interval. Therefore, there is no congestion packet drop! However, there is always the possibility of physical transmission errors that cause RTO timeouts and CWND resets to 1 MSS (which is very rare and does not significantly affect the improved throughput performance), To preempt timeout events / send sender transmission rate halving or reset to “0”, our “receiver-based” inter-packet inter-arrival technique and 3DUP ACK fast retransmission method are It can also be incorporated with the “scaled window size” method.

  Therefore, the flow per TCP here is to keep the transmission rate down (CWND reset to 1MSS) to cause a “sawtooth” transmission rate / throughput graph that consistently wastes half of the physical available bandwidth. There should be no RTO timeout, and the equivalent required reduction in transmission rate to avoid congestion packet drops is now only brought through the “pause” interval. → This transmission rate / throughput graph is now It must show a physical bandwidth that is almost always 100% utilization.

  An alternative way to preempt the “sawtooth” phenomenon described above without using a modified TCP is to set the sender TCP's maximum transmission window size, or TCPWindowSize system parameter value (and / or various other related parameter values). As a result, the maximum possible bandwidth delay product (maximum window size / RTT) value of the sender TCP never exceeds the physical bandwidth of the link, so this TCP flow will then utilize this link It is assumed that there is only one flow, so that no congestion packet drop can exist. When selecting an appropriate maximum TCPWindowSize value, the finite required for a packet of maximum allowed size (determined by the MTU value or MSS value) to completely exit on the lowest bandwidth link along the traversed path Time period should be added to the non-congested ping RTT (of very small negligible packet size) value for that particular source-destination, which is used in the bandwidth delay product equation (In real life, the actual RTT value should be larger when taking into account variations introduced by various components, such as the CPU ACK generation process ...) : In addition, if the returning ACK is probably piggybacked into a regular data packet (eg For example, if the receiver is also sending data symmetrically), the finite time to fully exit the lowest bandwidth link along the return traversed path of the largest data packet returned is still Should be added to the above to give us the minimum RTT value to be used in the bandwidth delay product equation. Assuming that the data packet stream is continuous, the finite time it takes for the largest allowable size data packet to exit the lowest bandwidth link along the traversed / returned path is negligible ( That is, the lowest bandwidth link still has a large bandwidth capacity, for example, it takes 50 ms for a 1500-byte data packet to go to the next forward link of 240 kbs, but a 1500-byte data packet is next to 56 kbs. It takes about 250 ms to exit the forward link of: For example, for a source-destination very small byte-sized ping packet RTT of 50 ms, such exit time is the minimum RTT value to be used in the maximum window size TCPWindowSize calculation. Governs the values that make up the computation of ) Assuming, Selective Acknowledgment option is should improve the performance of this case, Delay Acknowledgment option, even if it is enabled, any no practical effect.

TCP changes that can be deployed incrementally and instantly on the external Internet Currently, standard RFC TCP data transfer throughput can be achieved over paths / networks with high congestion drop rates and / or high BER rates (physical transmission bit error rates) It does not work well, especially with long distance fat pipe networks (LFN) with high RTT values and very large bandwidth paths. The constantly varying inherent AIMD (additive increase multiplicative decrease) sawtooth transmit waveform of standard RFC TCP varies wildly between 0% and well over 100% of the bandwidth capacity of the physical link / bottleneck link, This can also contribute to the packet drop itself.

  Currently, TCP halves its congestion window CWND size and thus halves its transmission rate during packet loss events notified via 3DUP ACK fast retransmission requests or RTO retransmission timeouts. Currently, TCP also cannot identify causes that are not congestion related to packet drop events, such as the BER effect, and treats all packet loss events as being caused by route / network congestion.

It is a common and well-documented phenomenon that a path with a total loss rate of only 1% halves the achievable TCP flow throughput. http: // internettrafficreport. com , the usual loss rate in Asia is 5% to 40% and in North America it is 2% to 10%.

  Here, all of the above-mentioned drawbacks on high loss rate paths / networks can be completely eliminated, can be instantly deployed on the external Internet incrementally, and can also be TCP flow friendly FIG. 6 shows an overview of improvements to an existing standard RFC TCP SACK based on a common principle (or various combinations of steps or subcomponent steps / processes or subcomponent processes).

  (1) In the event of a packet drop event notified by three DUP ACKs, the modified TCP of the present specification is the congestion window CWND by the number of bytes corresponding to the total segment / packet notified as lost / discarded. Should only need to reduce size (incoming DUP ACK packet (s) (trigger fast retransmission to increase / expand halved CWND size and / or subsequent DUP ACKs) ) The ACK Number field indicates the sequence number of the first lost packet, while the Selective Acknowledgment field indicates a block of consecutive sequence numbers that were successfully received out of order; that is, ACKNo and minimum SeqNo SACK Was The “missing gap (s) sequence” between the lock and the missing gap (s) SeqNo between the SACKed block itself is the missing discarded gap (s) Or) give us the sequence number of the packet (s) and thus the total number of bytes indicated to be discarded). However, the maximum SACKNo in the DUP ACK indicates the maximum SeqNo successfully received, which can optionally be used to increment the modified TCP CWND size accordingly ( As if the modified TCP maximum received ACKNo is now set to the maximum received SACKNo in the third DUP ACK that triggers fast retransmission and / or subsequent DUP ACKs However, it is only for the purpose / effect of increasing the CWND size / "effective window" size, and certainly not for the purpose / effect of advancing the left edge of the modified TCP sliding window: The end-to-end semantics of the TCP ACKNo field are otherwise standard Must be kept exactly as specified in the CP), and therefore in the same way with respect to the effect that the incoming ACKNo field has on the effective window size increment of the existing standard TCP, but never the left edge of the sliding window Forward (this is retained in the data for the current window size that can no longer be fast retransmitted / RTO timeout retransmitted to “Missing Gap (s) SeqNo”) Should be eliminated: where the subsequent increment of the received ACKNo is less than the above maximum SACKNo used to increment the CWND / valid window size, the modified TCP CWND / valid It should not have the effect of increasing the window size again, but it has changed. Note that it has the effect of advancing the left edge of the sliding window of TCP, not with respect to the effect of) but sending more segments / packets over the network with a modified TCP when it is SACKed than when it was ACKed / Allows to inject.

And / or (2) Upon a packet drop event signaled by a third DUP ACK, the modified TCP flow herein is the total number of outstanding transmitted flight bytes in the network (ie, the current Data transmitted to the network between when a packet carrying data having the same SeqNo as the ACKNo of the third DUP ACK is transmitted and when the current third DUP ACK having the same SeqNo arrives The total number of bytes of all transmitted packets, including encapsulation / header, whether the packet carrying the data or the control packet not carrying the data) is now adjusted to the same number as calculated below / Should only need to be guaranteed to be reduced to that number: this feature that triggers fast retransmissions. The total number of transmitted flight bytes sent to the network during the RTT of the fixed third DUP ACK, i.e. when sending a packet with the same SeqNo as the ACKNo of the third back DUP ACK that triggers a fast retransmission The total number of bytes sent to the network between the time of receipt of a particular third DUP ACK divided by minRTT divided by the RTT of this particular third DUP ACK.

  The minRTT is the latest estimate of the RTT that is actually not congested between the endpoints of the TCP flow, so all the flows that traverse the congestion drop node all work in harmony. This particular node here must then become non-congested or close to congested: the minRTT here is simply observed so far for the modified TCP flow Is the smallest recorded RTT value and should serve as the latest best estimate of the actual physical uncongested RTT for this flow (obviously, the actual physical uncongested RTT for the flow If is known or supplied in advance, it must be used instead, or it can be used).

  The total number of transmitted flight bytes sent to the network during the RTT of this particular third DUP ACK that triggers a fast retransmission, i.e., for packets with the same SeqNo as the third return DUP ACK that triggers a fast retransmission. The total number of transmitted flight bytes transmitted between the time of transmission and the reception of this particular 3rd DUP ACK is the SeqNo, TimeSent, and encapsulation / header of this packet including the transmitted packet. It can be derived by maintaining a time-ordered event entry list (ie purely based on the order of transmission to the network) consisting of a triple field called total_number_of_bytes. Thus, the RTT value of the third DUP ACK with a particular acknowledgment number is the current arrival time of this current third DUP ACK—the TimeSent of the packet carrying data with the same SeqNo as the current third return DUP ACK Can be derived as The total number of flight bytes sent can be derived as the sum of all the total_number_of_bytes fields of all entries between the event list entry with the same SeqNo as the returned third DUP ACK and the very last entry of the event list. .

  The size of this event list can be kept small by removing all entries that have a SeqNo less than the ACKNo of the third DUP ACK.

  A simplified alternative to the calculation of the total number of flight bytes transmitted is the maximum transmitted SeqNo− when sending / receiving a data packet with the same SeqNo as the ACKNo of the current 3rd DUP ACK to return. Approximate these as the largest ACKNo received: this gives the total number of net data segments in flight that do not include flight data segment bytes, ie, control packets that do not carry encapsulation / header / data.

  Various possible ways to implement changes to the existing standard RFC TCP source code to adjust / reduce the total number of outstanding transmitted flight bytes in the network during a packet drop event signaled by the third DUP ACK Among these are the following:

  . The total number of transmitted flight bytes sent to the network during this particular third DUP ACK RTT that triggers fast retransmission, ie, packets with SeqNo equal to the ACKNo of the third back DUP ACK that triggers fast retransmission The value obtained by dividing the total number of bytes transmitted to the network between the time of transmission and the reception of this specific 3DUP ACK by [the value obtained by dividing minRTT by the RTT of this specific 3DUP ACK] is the closest. Immediately reduce the current "valid window" size through reducing the congestion window or CWND size to be the same number rounded to bytes. This is appropriate for the congestion window CWND size to re-achieve its previous size before any new arriving back ACK (s) can "clock" out new packets to the network. The appropriate number of subsequent back ACKs should no longer have the effect of "clocking out" new packets to the network, as it needs to be incremented by a large number of subsequent back ACKs. Where the number of back ACKs required before the new packet (s) can be "clocked out" is the number of bytes that CWND acknowledges the same number of bytes. Or the number of return ACKs needed for the normal or normal.

  . Alternatively, instead of the decrement procedure described above, the CWND here is the RTT / minRTT of the arriving third DUP ACK * the number of transmitted segment bytes that are acknowledged by this arriving third DUP ACK. Will only be incremented at the rate of rounding to a fraction or carry forward (rather than incrementing by the number of segment bytes transmitted in normal standard RFC TCP, which is acknowledged by a new incoming ACK): Continue for all subsequent multiple identical or incremented ACKNo DUP ACKs or new ACKs until the reduction is achieved, and when the reduction is achieved, the reduction process stops. Some older TCP implementations may increment CWND by 1 SMSS for each new ACK that arrives, rather than incrementing by the number of segment bytes sent that are acknowledged by the new ACK that arrives, This decrement process could alternatively be brought about by only one 1 SMSS CWND increment for all other RTT / minRTT received ACKs received (only DUP ACKs with new ACKs). Yes, but rounded to the nearest integer, for example, if RTT / minRTT = 2.5, CWND can be incremented by 2 for all 5 incoming new ACKs). This has the effect of smoothing the flight byte reduction process, so there is still a properly reduced continuous transmission and reception of new packets throughout this flight byte reduction process.

  The congestion drop (s) notification event caused by the RTO timeout retransmission can be handled in the following manner.

  . Treat in the same manner as the third Dup ACK or subsequent DUP ACKs of the exact same ACKNo as described above, i.e. let the process of reducing the flight bytes remove the buffered residency packet However, the CWND size is not reset / decreased.

Or. Treat exactly the same as the existing standard RFC specification, ie reset CWND to 1SMSS and re-enter slow start exponential increments: But here the Ssthresh value in the modified TCP here Note that the slow start quickly increases again to the initial Ssthresh value (which has not been reduced by any successive fast retransmission events) since.

  In addition, for example, a subsequent multiple DUP ACK with the same unchanged ACKNo, a third DUP ACK with a new incremented ACKNo (or detected for example by a TCP retransmission without a third DUP ACK that triggers a fast retransmission) Subsequent congestion drop notification events, such as RTO timeout retransmissions), if the new computation does not require a larger decrease (ie, does not require a smaller total flight byte), the existing “ It must be possible to complete the “Flight Byte Reduction” process / procedure, otherwise this new process / procedure can be taken over as an option (and instead a specific “mark” Returned "SeqNo" and then Based on the checking whether there is a congestion drop notification event in RTT (1 s) can be such a process / procedure makes it possible to start only once per RTT).

  The modified TCP herein is modified because it can derive the RTT for a specific return ACK (or return ACK just before the RTO timeout retransmission) that causes congestion drop (s) event notification. The software can also detect if the same event as above was actually a “false” congestion drop (s) notification, and if so, it can react differently: The RTT associated with the congestion drop (s) event notification is the same as the endpoint's latest estimated non-congested RTT (or known / pre-supplied) or a single node in milliseconds This particular congestion drop (one or more) if it does not differ by a specified amount of variation within the bounds of the minimum buffer capacity equivalent. Notifications can be handled correctly as otherwise arising from physical transmission errors / destruction / BER (bit error rate), and the modified software causes / does not need to enter / enter the flight byte reduction process at all In addition, the notified discarded segment / packet can be simply retransmitted.

  Here, unlike the existing standard RFC TCP, the modified TCP of this specification is caused by multiple DUP ACKs and / or RTO timeout retransmissions of the same ACKNo following a new 3rd DUP ACK / new 3rd DUP ACK. It is not always necessary to automatically reduce / halve / reset the CWND size during a congestion drop (s) notification event that is received: the modified TCP herein is an unresolved flight In order to reduce the number of bytes to a suitably derived value, it is only necessary to properly reduce the CWND size in the event of congestion drop (s) notification event (s). Please keep in mind.

  All bottleneck links are always able to receive transmitted packets at the bottleneck's physical line rate, regardless of the buffer resiliency occupancy level and / or congestion drop (s) at the bottleneck node. Should continue to forward towards TCP → thus the sum of all bytes acknowledged during the RTT period (s) associated with the return ACK received at all sender TCPs is the bottle Note that whenever the neck bandwidth is fully utilized, it should be approximately constant and equal to the physical bandwidth of the bottleneck link. Also, the TCP congestion avoidance algorithm is a bandwidth utilization rather than a significantly lower utilization of the existing standard RFC TCP caused by CWND size halving at the congestion drop (s) notification event (s). Note that efforts should be made to keep as close to 100% of the bottleneck (s) link bandwidth as possible. A variety of different flight byte reduction levels / decrease amounts / decrease ratios / algorithms can be devised, such as at the time of congestion drop (s) notification event (s) and / or such historical events. Maximum received ACKNo and / or maximum transmitted SeqNo and / or CWND size and / or effective window size and / or RTT and / or minRTT. . . (E.g., taking into account an acceptable level of buffer resilience occupancy rather than completely clearing all buffer residencies packets / "extra" buffered flight bytes of the modified TCP flow Etc.) based on various other parameters.

And / or (3) The physical bottleneck link of a TCP connection over the Internet is usually either the last mile transmission medium of the receiver TCP or the first mile transmission medium of the sender TCP: these are usually 56 Kbs / 128 Kbs PSTN dialup or normal 256Kbs / 512Kbs / 1Mbs / 2Mbs ADSL link. In these situations, no matter how fast the sender TCP transmission rate (existing standard RFC TCP inevitably continues the bandwidth of the path by injecting increasingly larger bytes on each subsequent RTT. Probing and exponentially doubling CWND during slow start or linearly incrementing CWND during congestion avoidance), the bottleneck link Can only forward at the maximum line rate limited by its bandwidth → increase the transmission rate beyond the line rate of the current bottleneck link (the current bottleneck link sometimes changes depending on the network traffic) TCP flows that exceed the physical line rate of the bottleneck link (which may change) One or more) of not result in higher throughput. Thus, the TCP here can be advantageously modified not to transmit at a rate higher than the maximum possible physical line rate of the bottleneck link. Sending at a rate higher than the bottleneck link's maximum possible physical line rate would cause the amount of TCP / bytes transmitted during each RTT to exceed the “extra” bottleneck physical line rate by It is unavoidably buffered or thrown away somewhere along the endpoint.

Here is an example procedure among several possible ones that determine the physical bandwidth of a path bottleneck link:
. Continuous RTT values can be easily derived. This is because the existing standard RFC TCP already performs the calculation / derivation of consecutive RTT values based on “marked” TCP packets with a specific SeqNo for each consecutive RTT period. is there.

  . The throughput rate for each successive RTT is the total number of transmitted flight bytes sent to the network during the RTT for this particular “marked” SeqNo packet, ie the transmission of packets with this particular “marked” SeqNo. And the total number of transmitted flight bytes transmitted between the time of the return ACK (or SACKed) and the seqNo of the transmitted packet. By maintaining a time ordered event entry list (ie, purely based on the order of transmission to the network) consisting of a triplet field of TimeSent and the total_number_of_bytes of this packet including encapsulation / header Guidance It can be. Thus, the RTT value of a specific “marked” packet with a specific SeqNo is the current arrival time of this current return ACK (or SACKed) —the packet carrying the data with the specific “marked” SeqNo It can be derived as TimeSent. The total number of flight bytes sent can be derived as the sum of all the total_number_of_bytes fields of all entries between the event list entry with the same SeqNo as the returned third DUP ACK and the very last entry of the event list. . The size of this event list can be kept small by removing all entries that have a SeqNo less than the ACKNo of the third DUP ACK. A simplified alternative to calculating the total number of flight bytes transmitted is the maximum SeqNo transmitted on the arrival of the third DUP ACK + the number of data bytes in this maximum SeqNo packet-the maximum received These are approximated as ACKNos of: flight data segment bytes, ie, the total number of net data segments in flight that do not include control packets that do not carry encapsulation / header / data.

  Instead, as an approximation and / or simplification of the total number of transmitted flight bytes transmitted between the time of transmission of a packet with a particular “marked” SeqNo and the time of its returning ACK (or SACKed) , The throughput rate calculation / derivation of each successive RTT, the SeqNo of the specific “marked” packet + the data payload size in bytes of the specific “marked” packet−the specific “marked” SEQNo packet sent May be based on the maximum ACKNo received.

  The throughput rate of RTT here can thus be calculated as the total number derived on the transmitted flight bytes sent to the network during the RTT period / this RTT value (in seconds).

  . A record of the maximum throughput rate value achieved with all RTTs is maintained and continuously updated, and is referred to below as maxT. The RTT value associated with the period in which the maximum throughput rate maxT, hereinafter referred to as RTT_maxT, is also taken together with the total number of transmitted flight bytes associated with the period in which the maximum throughput rate maxT, hereinafter referred to as In_Flights_BYTES_maxT, is achieved. To be recorded.

  . Throughput rate in any RTT period <= maxT, ie whenever the throughput rate in this RTT period does not become> maxT, and IF [total number of flight bytes in this RTT period / In_Flights_Bytes_maxT]> [in this period RTT value in milliseconds / RTT_maxT in milliseconds] THEN The physical bandwidth capacity or line rate of the bottleneck link is now derived / obtained. The principle here is that the number of flight bytes in this RTT period is, for example, twice the number of flight bytes related to the maxT period, and the RTT value in this period is the same as (or less than twice) the RTT_maxT, for example. The reason why the throughput rate of this RTT does not exceed maxT if it remains is because maxT is already the same as the physical bandwidth capacity / line rate of the bottleneck link, and therefore further during this RTT period This is because the throughput rate within this RTT, which is limited by the bottleneck line rate, does not increase beyond maxT, even though many flight bytes and this RTT value did not increase disproportionately. The test formula includes a mathematical dispersion tolerance, eg IF [total number of flight bytes during this RTT period / In_Flights_Bytes_maxT]> [RTT value in milliseconds during this period / RTT_maxT in milliseconds] * dispersion tolerance ( For example, 1.05 / 1.10.

  . If the true bottleneck link physical bandwidth capacity / line rate is derived / obtained (= maxT), the modified TCP no longer causes unnecessary congestion packet drops and / or burst packet drops. It is not possible to continuously probe for path bandwidth aggressively like the slow start exponential CWND increments / congestion avoidance linear CWND increments per RTT of the existing RFC standard TCP that constantly strives to do so. Here, the modified TCP then converts all subsequent increments of CWND size (optionally and / or effective window size) within all subsequent next RTT periods to [maxT (now bottleneck circuit CWND size (optionally and / or effective window size) associated with maxT when (equal to rate) is achieved * (last previous or latest RTT value in milliseconds / RTT_maxT in milliseconds) It can be limited not to exceed 5%. Although very unlikely, if the throughput rate at any subsequent RTT is greater than maxT, maxT is updated and the bottleneck line rate determination process is repeated once more. Thus, the modified TCP goes beyond what is necessary to keep the bottleneck link busy at its line rate, and unnecessarily aggressively increments the CWND size and / or effective window size to reduce congestion drop and / or Or it does not cause a burst packet drop.

  Alternatively, the modified TCP can optionally rate pacing its packet generation / packet transmission to the network, ie, the modified TCP is at the maxT bottleneck line rate: Set minimum Inter-Bytes_forwarding_Interval = (1 / (maxT / 8)) after the bottleneck's true line rate is achieved / equal, otherwise, optionally, the minimum Inter-Bytes_forwarding_Interval By setting = (1 / (maxT / 8)) * 2 (since the CWND increase at this time should at most double the CWND of the previous RTT period exponentially) / Send packet I just believe.

  . Further, optionally, the modified TCP relates to the discarded packets described during the "extra" flight byte clearing and / or congestion drop (s) notification event (s). The packet generation / packet transmission rate is always the corresponding maxT rate, not the packet generation / packet transmission rate allowed / "clocked out" by the returning ACK (or SACKed) rate, subject to an appropriate rate reduction. (Whether maxT has already achieved a rate equal to the bottleneck's true line rate or just the latest maxT): That is, the modified TCP is optional Providing a suitable rate reduction to clear / reduce flight bytes and Or reduce the rate corresponding to the number of discarded packets (eg, congestion drop notification event (may be a third DUP ACK and / or a subsequent DUPACK and / or RTO timeout retransmission of multiple identical ACKNos)) The packet generation / transmission rate in equivalent bits per second, for example, maxT * minRTT / RTT value of this period or maxT-reducing the number of bytes discarded during this RTT * 8) Packets are generated / transmitted at an unrestricted latest maxT rate that is not limited by the ACK (or SACKed) return rate.

Embodiments that do not directly modify existing TCP source code:
Without directly changing the TCP source code, the invention described in the previous paragraph can be implemented as an independent TCP packet intercept software / agent, where the software is transferred for one sliding window. Rate pacing (maxT for forward forwarding of intercepted packets going to / from local TCP and / or all fast retransmissions and / or RTO timeout retransmissions According to the value), that is, the transfer rate adjustment process at the time of congestion drop notification event.

Here is an overview of such an implementation, purely to provide an overview of the necessary steps that can be improved / changed. Furthermore, all the refined and detailed algorithmic / coding steps are purely for illustrative purposes only and can be improved / modified:
. The intercept software intercepts every packet that comes from TCP / addressed to MSTCP.

  . The software maintains a copy of the packet carrying all the data payloads in a clearly ordered list entry according to increasing SeqNo.

  . Upon the third DUP ACK notification, the software performs fast retransmission from the data payload packet copy entry on the list having the same SeqNo as the third DUP ACK and the subsequent multiple DUP ACKs of the same ACKNo. The software stores the cumulative number of DUP ACK (s) with the same ACKNo value as DupNum, and all discarded packets indicated by "Gap (s)" in the Selective Acknowledgment field. To resend fast. The software changes the ACKNo of each all DUP ACK (s) by decrementing the ACKNo value of this packet (s) to ACKNo-DupNum * eg 1500, so TCP Absolutely never receive a DUP ACK with the same ACKNo → TCP never reduces / halves CWND size due to fast retransmissions (this is currently taken care of by software). The software does not reduce any CWND size values (this parameter is not accessible by software).

  . The software incorporates the principles / processes / procedures or combinations / subcomponents outlined in the general principles previously described.

further,
. The software can even perform a complete RTO timeout retransmission on behalf of MSTCP (by incorporating the RTO calculation from the historical return ACK RTT value): Can immediately "spoof ACK" all single packets when receiving one or more)-> TCP now does not even do RTO timeout retransmissions. The software can also “delay” ACK spoofing when receiving packet (s) from TCP as a technique to control TCP packet generation rate / TCP packet transmission rate.

  . Rather than changing the TCP CWND size / effective window size (not accessible from the software) this is not an essential required feature, but the software is instead in the software itself Simulate "mirror CWND mechanism / mirror effective window mechanism", or alternatively rate pacing to control / adjust other parameter values such as largeRcvACKNo, largeSentSeqNo, size that requires subtraction difference To ensure that . . Any of the other equivalent forms, such as the reduction of flight bite through, can do any of the same effects.

  . The software defines checksum verification, SeqNo wraparound detection and comparison, timestamp wraparound detection and comparison for each and every intercepted packet as defined in the existing standard RFC. . . Various standard TCP techniques such as can also be implemented.

  Here are some simple overviews about software design that can be further corrected / improved / modified and / or designed completely differently, purely for illustration purposes only.

1. Pure intercept transfer:
2. + Checksum + Wraparound:
3. + Fast retransmission of only the same DUPACKed packet copy once for the same DUP ACKNo:
4). + Fast retransmission of all packet copies once for the same DUP ACKNo:
5. + Fast retransmission of only all packet copies up to the largest SACKed “gap (s)” once for DUP ACKs of the same ACKNo:
6). + Fast retransmissions only for all packet copies of> LARGESTRTXSEQNo up to the maximum SACKed “gap (s)” for each DUPACK: (the software is DUP ACK and / or new for each subsequent same ACKNo Do not want to repeat DUP ACK with incremented ACKNo multiple times unnecessarily, and do not unnecessarily retransmit another packet that has already been retransmitted at the same time when receiving DUP ACK with the same ACKNo. In order to do so, the SeqNo of the largest fast retransmitted packet, ie LargeRtxSeqNo, can be recorded / updated.

later,
7). + Inter-packet transfer interval (determined by user input of known bottleneck line rate in advance):
8). As with + (7), use the latest estimated bottleneck line rate rather than user input. + TCP friendly algorithm operating via control / adjustment of interval value between packet transfers Simple overview of the initial basic rate pace module:
First stage rate pace module specification that must be added (this specification only performs smoothing of packet transmissions to the network and does nothing else):
1. Let the user enter the bandwidth in kbs of the bottleneck link, eg SAN. exe B (eg 512 kbps): This is usually the sender / user's first mile upload bandwidth, but can sometimes be the receiver's last mile (if the user does not know the receiver's last mile bandwidth) Simply enter the user's first mile: DSL subscriber upload bandwidth is usually much less than download bandwidth) [later software is estimated up-to-date without requiring any user input Can provide a value of B].

  2. Incorporates a simple rate pace module that guarantees transfer between minimum byte intervals, eg S2 (eg 750 bytes this time) when transferring a packet of size S1 (eg 1000 bytes full length, encapsulation + header + payload) 1000 bytes / (B / 8) elapses before the next packet size is transferred. . . Make sure. . . The total packet size S can be confirmed from the TCP header.

  3. New MSTCP packet / Fast retransmission / RTO retransmission. . . Any packet to be forwarded is first appended to the packet buffer to be forwarded: this buffer most often needs to be clearly ordered, but not "gapless" And arriving packets from either MSTCP or software fast retransmission are appended / inserted in SeqNo ascending order (ie, fast resend / MSTCP RTO resend packets have other SeqNo To be transmitted first before the data packet). The same SeqNo pure ACK / data packets would need to be inserted in the order of relative arrival with respect to each other.

  (Note: MSTCP here continues to perform all RTO retransmissions).

[Enhancements to later specification functions:
. Round Trip A single marked packet SeqNo. . . And the SeqNo. Of the next forwarded packet following the completion of the round trip. . . It is useful to add a Total Packet Length in Bytes field to the packet entry in the list to be forwarded for a simple count of the total transmitted bytes for each RTT based on It is. This list is different from the Packet Copy list that needs to be paced and must not be “gapless” here, which must be clearly ordered in this first stage.

  . When the buffer to be transferred is greater than 10 Kbytes, for example, a “0” window update is always transmitted to MSTCP, and the window size of all incoming packets is changed to a “0” recalculation checksum.

  . “Mark” the packet's SeqNo (starting with the first packet after SYNC / SYNC ACK / ACK) / send time / this_RTT_total_bytes_forwarded = set the length of this “mark” packet and immediately next_RTT_total_bytes_forwarded Start counting (does not include this “mark” packet). If ACKNo> “mark” SeqNo of the returning packet, this RTT value (current system time-transmission time) is recorded, and this_RTT_total_bytes_forwarded is recorded. Then select the next “mark” SeqNo as the SeqNo of the most recently forwarded packet (if there is a data packet instead of a pure ACK forwarded before the previous “mark” SeqNo returns, otherwise Wait for the next data packet to be transferred). . . . . . Such. . . . . Such.

(It is only necessary to keep record-only for the latest updated instance of RTT value and this_RTT_total_bytes_forwarded)
. The software must increment the DupNum count only if the DUPACK packet is a pure ACK, ie it is not carrying data or is a packet carrying data with the SACK flag set (the remote client also has data We may start to get a number of identical SeqNo packets even if there are no drops). It also increments another variable DupNumData (the number of data payload packets with the same SeqNo) and changes all incoming packets with the same SeqNo to-(DupNum + DupNumData): DupNumData is updated in a manner similar to DupNum , DupNum processing now needs to distinguish between pure DUPACK packets and packets with data payloads.

  The various component features of all the methods and principles described herein can be further incorporated into any of the illustrated methods to work together, with various topology network types and / or various The methods and principles of traffic / graph analysis may further enable link bandwidth economy. Wherever it appears in this description, the numbers used are intended to show only specific examples of possible values, for example, RTT * 1.5 will change the number 1.5 to the intended and specific network. Another suitable value setting (but always greater than 1.0), eg 0.1 sec / 0.25 sec. . . Note also that it can be replaced by a perception period such as. Moreover, all of the specific examples and numbers shown are intended to convey the underlying ideas, concepts, and their interactions, but are not limited to the actual numbers and examples used.

  The embodiments described above merely illustrate the principles of the invention. Those skilled in the art can implement the principles of the invention and make various modifications and changes included therein.

Filing October 11, 2005
Some examples of a simple implementation of an incrementally deployable external Internet NextGen TCP Background material The most recent RTT of the packet that triggers the third DUP ACK fast retransmission or triggers the RTO timeout is readily available from variables maintained in the existing Linux TCB for the last measured round trip time RTT.

  . The minimum recorded min (RTT) is only readily available from variables maintained in the existing Westwood / FastTCP / Vegas TCB, but min (RTT) = [min (RTT), last measurement It must be simple enough to write a few lines of code that continually update the minimum value of the [roundtrip time RTT]. Also, with receiver-based TCP modification / receiver-based TCP rate control, OTT and min (OTT) can be used instead of sender-based RTT and min (RTT), which is available from the sender's Timestamp option. Benefits can be gained, or receiver-based TCP can make use of inter-packet arrival techniques rather than relying on the need to ascertain OTT and min (OTT).

References:
http: // www. cs. umd. edu / ~ shankar / 417-Notes / 5-note-transportContControl. htm : RTT variable maintained by Linux TCB
http: // www. scit. wlv. ac. uk / rfc / rfc29xx / RFC2988. html : RTO calculation Google Search term “tcp rtt variables”
http: // www. psc. edu / networking / perf_tune. html : Tuning of Linux TCP RTT parameter Google Search: “tcp minimum recorded rtt” or “linux tcp minimum recorded rtt variable”. Note: TCP Westwood measures the minimum RTT.

  Google Search terminology “CWND size tracking”, “CWND size estimation”, “Receiver based CWn size tracking estimation”, “RTT tracking”, “RTT estimation”, “RTT estimation”, “RTT estimation”, “RTT estimation” ”,“ Receiver based OTT tracking estimation ”,“ total in-flights-packets tracking ”,“ total in-flights-packets estimation ”,“ Receiver based ” otal in-flight-packets tracking estimation ". . . Such.

To verify testing using an early-implemented idea- modified Linux:
The simplest and sufficient, it is only necessary to change one line and insert a loop delay code (to “pause” Linux TCP execution).

  1. In the Linux fast retransmit module code, CWND is not halved on 3 DUP ACKs, ie CWND is not currently changed (not CWND = CWND / 2).

2. At the same time, simply insert 2-3 lines of code at the same code section location to “pause” (simulate “pause”) the execution of the Linux TCP program for 0.3 seconds. [Later only: Resend the very first DUP ACKed packet unconstrained, then just set the 300ms countdown global variable "Pause" at this same position, after which Linux TCP In the “Last Packet Transmission” code section, check that this “Pause” variable = 0 to allow any kind of transmission (since Linux holds packets stopped by this “Pause”) (Assuming to implement a “last send” queue)
Write a few lines of code that discards the packet and introduces a latency delay before sending the packet, simply a constant periodic drop interval of user input and the number of consecutive drops (eg, 0.125). And one, i.e. discard one packet once every eight generated packets [equivalent to 12.5% packet loss rate] or 0.125 and three, i.e. once every eight generated packets It is much preferred to allow three consecutive packets (equivalent to 37.5% packet loss rate)) and to allow RTT latency (eg, 200 ms).

  The code simply requires not forwarding forward based on the drop interval and the number of consecutive drops, and that all scheduled surviving packets are forwarded eg 200 ms after the received local system → These surviving packets scheduled to be forwarded need to be held in a queue for forward forwarding to the network (its own individual scheduled forward forwarding local system With).

  Quickly verify along with various simulated loss rates and latency on a 10 mbs LAN and a wireless router link tuned to 500 kbs (don't forget to set Ethernet to “half-duplex” mode) Can do. In its simplest and sufficient, it is only necessary to change one line and insert a loop delay code (to “pause” Linux TCP execution).

  1. In the Linux fast retransmit module code, CWND is not halved on 3 DUP ACKs, ie CWND is not currently changed (not CWND = CWND / 2).

  2. At the same time, at the same code section position, simply insert a few lines of code to “pause” the execution of the Linux TCP program for 0.3 seconds (simulate “pause”).

  High Loss Rate Long Latency Large File Transfer SAN FTP over external Internet / LFN must now show usable bandwidth utilization close to 100%! . For example, you can simulate the 10% drop rate and / or 300ms latency, i.e. long distance high loss rate, across the Shura software, or simply discard the packet, Code can be written that introduces a latency delay before sending. This can also be easily verified using simulations such as NS2.

  Now, the current size of Sender TCP's CWND does not cause congestion drops in any way, as this size is achieved, it only injects new packets exactly corresponding to the ACK rate that Sender TCP returns. It is very clear: note that this is an accelerated instantaneous increase in CWND size (injecting more packets into the network momentarily than the return ACK rate, eg, twice that of the return ACK rate) Exponential increment, which is the main cause of packet drops: no matter how large if CWND has already achieved the current existing size, it will inject more new packets into the network than the return ACK rate This happens only at the momentary size increment of CWND Get).

  Changing the Linux source code in a few lines is quite simple, and Windows only needs to prepare an intercept software module that takes over all the fast retransmission functions from MSTCP first. To implement on Windows, MSTCP intercepts each incoming / outgoing packet and changes the Acknowledgment Number field in the incoming DUP ACK so that MSTCP is not notified / knows about lost packet fast retransmission requests (Not MSTCP, our intercept software now does all the fast retransmission functions): This intercept software module can also take over all RTO timeout retransmission functions from MSTCP ( For example, you can mirror the RTCP timeout tracking algorithm of MSTCP itself or devise a new modified desired algorithm). With the intercept software module now taking over all of the existing MSTCP DUP ACK fast resend and RTO timeout resend functions, the intercept software now instantly spoofs the SPOF ACK back to MSTCP for intercepted packets. Has full total control over MSTCP new packet generation / transmission rate via setting “0” in receiver window size field in SPOF ACK to stop / temporarily stop and / or stop MSTCP packet generation be able to.

  For example, in Linux / FreeBSD / Windows source code, it should be possible to modify / insert a few lines to have this NextGenFTP immediately shown to work in the following very basic form.

  1. In the Linux 3DUP ACK fast retransmission module, it is only necessary to remove the code line that changes CWND to CWND / 2 (ie, CWND is no longer changed). All other code lines do not need to be modified at all: for example, SSthresh is now set to CWND (ie, TCP is now not exponentially doubling, for all RTTs It only increases additively by one segment). This in itself must now show close to 100% link utilization on LFN / external internet with high drop rate! (Ie shown to work in a very unfinished form here).

  To help with testing, use software such as Shura that can introduce% packet drop and / or simulate path latency, and place this software between NextGenFTP and the sender of the network A similar simple utility may be coded.

  2. [Optional but certainly necessary later] NextGenFTP is actually buffered itself, "paused" for a suitable interval during a packet drop event, such as three DUP ACKs. Must clear all of the "extra" transmitted flight packets (but all existing regular TCP / FTP dramatically halves its CWND, and seriously unnecessarily clearly documented Caused throughput problems). For example, in Linux, if the actual actual non-congested RTT or non-congested OTT is not known in advance, the minimum observed RTT record min (RTT) or min (OTT) of the flow is maintained and upon 3DUP ACK For example, all packet injections into the network for 0.3 seconds (which is the most common router buffer size in equivalent seconds) or for some algorithmically derived period (after ...) It is only necessary to insert some code that “stops” [note that instead of pause, the corresponding algorithmically determined value (s) appropriate to CWND can also be set. ! . Depending on the desired algorithm devised, {latest RTT value (or OTT if appropriate)-recorded min (RTT) value (or min (OTT) if appropriate)} / min (RTT) times Decrease CWND size only, or [{latest RTT value (or OTT if appropriate)-recorded min (RTT) value (or min (OTT) if appropriate)}} / latest RTT value] Reduce the CWND size by a factor of two, i.e. CWND * [1-[{latest RTT value (or OTT where appropriate)-recorded min (RTT) value (or min (OTT) where appropriate) )} / Latest RTT value]] or CWND * min (RTT) (or min (OTT) where appropriate) / latest RTT value ( That, to set the OTT) where appropriate. . . . Etc.]. Note that min (RTT) is the latest estimate of recorded path non-congested RTT.

  3. [Optional but certainly necessary later] The usable bandwidth of the bottleneck link along the path of the flow can be easily determined (very clearly documented, but our own Therefore, if this upper limit of available bandwidth is known / determined, NextGenTCP should no longer cause CWND increments (exponential) → NextGenTCP no longer unnecessarily causes CWND increments and unnecessarily pulls packet drops if transmitted at this achieved ceiling rate! .

Early simple implementation idea (sophistication 1):
To verify testing using the modified Linux:
The simplest and sufficient, it is only necessary to change one line and insert a loop delay code (to “pause” Linux TCP execution).

  1. In the Linux fast retransmit module code, CWND is not halved on 3 DUP ACKs, ie CWND is not currently changed (not CWND = CWND / 2).

  2. At the same time, at the same code section position, simply insert a few lines of code to “pause” the execution of the Linux TCP program for 0.3 seconds (simulate “pause”). [After: retransmit the very first packet, then just set the 300ms countdown global variable "Pause" at this same position, then Linux TCP will do whatever it does in its "Last Packet Transmission" code section Check that this “Pause” variable = 0 to allow all kinds of transmissions (assuming that Linux implements a “Last Send” queue to hold packets stopped by this “Pause” It is much preferable to be able to).

  [Only later: Resend the very first packet, then just set the 300ms countdown global variable "Pause" at this same position, then Linux TCP will have its "Last packet transmission" code section Check that this “Pause” variable = 0 to allow any kind of transmission (Linux implements a “Last Send” queue to hold packets stopped by this “Pause” It is much preferable to be able to (assuming that).

Much later only : This can be conveniently achieved / implemented by (only as a suggestion):

  1. In the Linux fast retransmit module code, CWND is not halved on 3 DUP ACKs, ie CWND is not currently changed (not CWND = CWND / 2).

  2. At the same time, at the same code section position, simply set the 300ms countdown global variable "Pause" at this same position (exactly where CWND is now changed so that it is no longer changed rather than CWND / 2) Then, in the “Last Packet Transmission” code section, Linux TCP has the SeqNo = <maximum transmitted unacknowledged SeqNo (this SeqNo can be easily obtained from existing TCP parameters, ie All types of transmissions except when the packet is an old SeqNo packet to be retransmitted, except that it only allows the packet to be forwarded regardless of the “Pause” variable> 0 This "Pause" variable = 0 to enable Check that.

That is, Linux TCP always allows all fast retransmission packets and / or RTO timeout retransmission packets to be forwarded immediately and unconstrained regardless of CWND or effective window size constraints. (Retransmit packets do not increment any existing flight packet in any way! However, forward forwarding of a new packet with SeqNo> maximum transmitted unacknowledged SeqNo will result in an existing total flight packet Note that it may increase the number).

  Another embodiment is simply to derive a “pause” variable (such as a fixed 300 ms interval or the latest RTT-min (RTT) interval, etc.) during a congestion drop event (s). In order to count down, the CWND should never be decremented at all, and if the “pause” variable> 0, no CWND increment would be possible → this implementation would be Aggressive in that it does not help reduce extra flight packets that are buffered [Also, CWND, along with both Step 1 and Step 2, can be either "0" or large. UNA. SeqNo-SEnt. UNA. Rather than setting SeqNo, it can simply not be changed / decremented.

  This non-incremental part can also be introduced in the previous embodiment below while the “pause” variable> 0, so that the back ACK advances the left edge of the sliding window will result in a back ACK-clocking rate. Rate of ACK to return, only causing new packet (s) to be injected at the same corresponding rate (ie, packet (s) with SeqNo> largest.Sent.SeqNo) Do not cause “accelerated” CWND increments / extra accelerating exponential or linear new packet (s) injection beyond the clocking rate. When the countdown “pause” global variable> 0, Linux TCP should not increment CWND at all, even if the incoming ACK now advances the sliding window left edge. . . That is, Linux TCP can inject new packets into the network at the same rate as the returning ACK-clocking rate, but "exponentially doubles" beyond the returning ACK rate-clocking rate. Or "do not increase linearly" (change all CWND increment code lines to first check if the countdown "pause"> 0 and if so, bypass the increment Easy to implement).

  Alternatively, Linux changes can simply require the following:

  1. The CWND value is not changed / decremented at all during the congestion drop event (s) and is triggered by the congestion drop event, followed by a “pause interval”, eg 300 ms (or the latest RTT-min (RTT) ... or max [algorithmically derived interval such as latest RTT-min (RTT), eg 300 ms] ...) CWND is not incremented at all → congestion drop event (s) At this time, the modified Linux TCP sends new “accelerated” packet (s) to the network (ie, SeqNo> largeest.) Beyond the returning ACK clocking rate during the “triggered pause interval”. Sent.SeqNo (does not inject) [ie CWND , CWND <even if the sender / receiver maximum window size, increment not by returning proceeded left edge of the sliding window ACK].

And / or as an option,
2. It always makes it possible to forward retransmission packets (ie packets with SeqNo = <largest.Sent.SeqNo) forward without any restriction by the sliding window mechanism.

  Step 1. . . . . More refined against. . . . . For example, a 300 ms “pause” countdown that sets (Largest.SENT.SeqNo-SENT.UNA.SeqNo) to CWND is set, and CWND is restored after the countdown. . . → In this manner, the Linux high-speed retransmission module causes the DUP ACK of the same SeqNo that arrives after each of SENT. SeqNo-SENT. UNA. Since it increments to SeqNo + 1, the missing gap packet indicated by the SACK field of multiple subsequent DUP ACKs of the same SeqNo can be “stroked out” [missing when setting CWND to “0”. Can prevent re-transmissions forward in front of gap packets] → The change in step 1 itself should work pretty well without the need for step 2, but the change in steps 1 and 2 together If it is used for CWND, even if “0” is set in CWND, there is not much problem.

  In CWND, Largest. SENT. SeqNo-SENT. UNA. Setting SeqNo has the same effect as setting “0” in preventing “accelerated” new additional packets from being injected into the network, but retransmitted packets (SeqNo = < Largest.SENT.SeqNo) can be forwarded unconstrained.

Summary of TCP source code changes and simplified testing for existing RFCs:
The test bed should be as follows (compared to an unmodified Linux TCP server):

Modified Linux TCP server [+ Simulated packet drop of eg 2/5/20% + RTT latency of eg 100/250/500 ms]->Router-> Existing Linux TCP client Between router and client The link can be 500 kbps and the router can have 10 or 25 packet buffers. For example, sender / receiver window size of 32/64 / 256K bytes.

Proposed Linux TCP change specifications:
(Simple technique for achieving a “transmit pause” for a simple real-world Linux implementation, eg by setting CWND = 0 during the 300 ms interval)
1. In the event of a congestion drop event (three DUP ACKs that halve CWND and an RTO timeout that resets CWND to 0), existing Linux TCP instead multiplicatively reduces CWND to keep CWND unchanged ( CWND = CWND / 2), set (Largest.SENT.SeqNo-SENT.UNA.SeqNo) to CWND, set 300ms “pause” countdown, and if CWND is restored after countdown, be sure to halve Or Largest. SENT. SeqNo-SENT. UNA. The original CWND value, not the SeqNo CWND value, must also be set to SSThresh ==> This is exactly equivalent to a simple implementation that "pauses" for 0.3 seconds.

[Step 2 here is optional but can be preferred and can be added after a test with only Step 1]
2. CWND / valid window sliding window Regardless of window slot availability, all retransmission packets with SeqNo = <maximum existing transmitted SeqNo are enabled unconstrained.

  Sliding window code that checks for whether the TCP can be immediately forwarded forward (ie, depending on whether Largest.SENT.SeqNo-SENT.UNA.SeqNo <effective window size) In the section, we have SEqNo = <Largest. SENT. If it is a SeqNo (ie a retransmit packet, this should not be prevented from forwarding forward in any way), a code that “bypasses” this check can be inserted very simply → In this way, the Linux TCP retransmission module can always “stroke out” all “missing gap packets” indicated by the third DUP ACK / subsequent DUP ACKs. [Remember to incorporate SeqNo wraparound protection].

Useful Notes on Windows Platform Intercept Fast Retransmission Module This module takes over all fast resend functionality from MSTCP and sets the incoming ACKNo for incoming DUP ACKs so that MSTCP never knows any DUP ACK events at all Change), all “missing gap packets” indicated by the SACK field of the incoming DUP ACK of the same SeqNo must be retransmitted, and all retransmitted during multiple DUP ACKs of this same SeqNo If a subsequent DUP ACK of the same SeqNo indicates reception of the retransmitted SeqNo packet (s) above this “retransmitted list” (in this case, this module Is eqNo <"Missing gap packet retransmitted earlier" (ie already in the retransmitted list) with the largest retransmitted SeqNo received indicated by a DUP ACK for the same newly arrived SeqNo ) Is not retransmitted unnecessarily in the subsequent series of SeqNo DUP ACKs, except that it must be retransmitted again).

  Of course, in the subsequent new incremented SeqNo 3rd DUP ACK (SeqNo is now different and incremented), this module will send all the “indications” indicated by the SACK field of the incoming SeqNo DUP ACK of the same SeqNo. A “missing gap packet” can be retransmitted again.

Obviously, in subsequent version (s) to the version / algorithm described above, it is preferable to do the following:
“1. In the event of a congestion drop event (three DUP ACKs that halve CWND and an RTO timeout that resets CWND to 1), existing Linux TCP will instead CWND multiplicatively to leave CWND unchanged. (CWND = CWND / 2 or CWND = 1 in case of RTO timeout) and set CWND to 1 (trigger third DUP ACK fast retransmission or latest RTT-min of packet triggering RTO timeout ( RTT), 300 ms) minimum value “pause” countdown is set, and after the countdown, the current Largest. SENT. SeqNo-SENT. UNA. When restoring to SeqNo (which may be a completely different value than when “pause” was first activated), be sure to use Largest. Instead of a halved or “1” CWND value. SENT. SeqNo-SENT. UNA. The SeqNo value (when "pause" is triggered) must also be set to SSThresh ==> This is exactly equivalent to a simple implementation that "pauses" for 0.3 seconds. "

  Note: In this way, after the “pause” counts down, the modified Linux TCP will return ACK-clocking accumulated during the “triggered pause” interval to drop the link again immediately and once again to congestion congestion. Does not cause a sudden “burst” transmission, but only transmits at a subsequent return ACK-clocking rate after the “pause” has counted down (ie, accumulated back during the “pause” interval). Does not contain any of the ACK-clocking tokens.

Even more preferably : “1. Existing Linux TCP leaves CWND unchanged instead during congestion drop event (3 DUP ACKs halving CWND and RTO timeout resetting CWND to 1) Therefore, CWND is reduced multiplicatively (CWND = CWND / 2 or CWND = 1 in case of RTO timeout), and Large.SENT.SeqNo-SENT.UNA.SeqNo is set in CWND [Note: This CWND is not 1 Setting the value allows all retransmitted packets, ie packets with SeqNo = <Largest.SENT.SeqNo, to be forwarded immediately, without any restrictions due to sliding window slot availability, After "it was countdown, the current Largest. SENT. SeqNo-SENT. UNA. Note that SeqNo is still the same as if CWND was set to “1” instead before “pause” countdown] (trigger third DUP ACK fast retransmission or RTO timeout Set the minimum “pause” countdown of the latest RTT-min (RTT), 300 ms) of the packet that triggers the current Largest.CWND after the “pause” countdown. SENT. SeqNo-SENT. UNA. When restoring to SeqNo (which may be a completely different value than when “pause” was first activated), be sure to use Largest. Instead of a halved or “1” CWND value. SENT. SeqNo-SENT. UNA. The SeqNo value (when "pause" is triggered) must also be set to SSThresh-> this is exactly equivalent to a simple implementation that "pauses" for 0.3 seconds. "

TCP source code changes and simplified testing for existing RFCs (Sophistication 1):
This initial simplest Step 1 TCP source code change must be made alone to confirm the bandwidth utilization of the available link, which is initially close to 100%.

The specific setting test bed should be as follows (eg compared to an unmodified Linux / FreeBSD / Windows TCP server):
Modified Linux TCP server-> 1 drop in 10 simulated packets (can be implemented using IPCHAIN) 200ms RTT latency (preferably larger)->Router-> Existing Linux TCP The link between the client router and the client can be 1 mps (preferably larger), and the router is 1 mns * eg 0.3 * selected pause value / 8 = 40K bytes (ie 40 1 Kbyte packet) buffer size. Sender and receiver window size of 64K bytes (preferably larger).

Proposal of the first and simplest one-step Linux TCP change specification:
(Simple technique for achieving a “transmit pause” for a simple real-world Linux implementation, eg by setting CWND = 0 during the 300 ms interval)
1. In the event of a congestion drop event (three DUP ACKs that halve CWND and an RTO timeout that resets CWND to 1), existing Linux TCP will instead reduce CWND multiplicatively to keep CWND unchanged ( CWND = CWND / 2 or CWND = 1 when RTO times out), set 300W “pause” countdown to set CWND to 1, and if CWND is restored to its original value after being counted down, it must be half The original CWND value must also be set to SSThresh rather than the CWND value set to “1” or not → This is exactly equivalent to a simple implementation that “pauses” for 0.3 seconds.

  Note: This is except for the very first retransmission packet when the third DUP ACK triggers the fast retransmission mechanism and when the RTO times out (these are always forwarded by Linux TCP, regardless of sliding window slot availability). Forwarded!), Stop all transmissions / retransmissions forwarded by, eg, 300 ms at the time of the third DUP ACK and RTO timeout (to clear the buffer). Also, all subsequent multiple fast retransmission packets that are stopped / stopped by this 300ms “pause” are forwarded as soon as 300ms counts down (CWND reaches maximum transmit / receive window size). Only if not, we do not decrement any CWND, so it is likely that the CWND has already exceeded the maximum transmit / receive window size and is therefore stopped / stopped by this 300ms "pause" Subsequent multiple fast retransmission packets are likely only forwarded forward at the same rate as the returning ACK-clocking rate when 300 ms counts down (but fortunately this 300 ms pause period) Including all back ACKs accumulated in) ==> Most of this change Net ones, already, Google / Yahoo / Amazon / Real Player ... would be a "tremendous" commercial success on such.

TCP source code changes and simplified testing for existing RFCs (Sophistication 2):
“1. In the event of a congestion drop event (three DUP ACKs that halve CWND and an RTO timeout that resets CWND to 1), existing Linux TCP will instead CWND multiplicatively to leave CWND unchanged. (CWND = CWND / 2 or CWND = 1 in case of RTO timeout) and set CWND to 1 (trigger third DUP ACK fast retransmission or latest RTT-min of packet triggering RTO timeout ( RTT), 300 ms) minimum value “pause” countdown is set, and if CWND is restored to the original value after being counted down, it is always the original CWND, not the halved or “1” CWND value Must also set the value to SSThresh Shall → This is exactly equivalent to the simple embodiment to 0.3 seconds "pause"".

  Note: In this way, the packet drop event is changed when triggered by a physical transmission error / BER rather than the expected normal full buffer exhaustion (normal buffer size is 300ms) that causes the drop. Linux TCP does not “pause” and stop any forward forwarding unnecessarily: “pause” countdown if packet drop is caused by BER and link is not congested Is now correctly set to 0 ms rather than looping a permanent 300 ms permanent “pause”. Note that earlier IPCHAIN methods that simulate packet drop events do not respond to congestion or full buffer exhaustion events at all.

  However, the earlier, modified specification below still works, but the test bed now must instead:

Unmodified with 5 multiple large FTP and / or congested traffic generators (e.g. even periodic 300ms UDP congestion burst generation every 1.5 seconds, for example) to router 1 over a 1 mbs link, for example Linux TCP server ↓ (1mbs link)
Modified Linux TCP server-> (1 mbs link) Router 1 (1 mbs link)-> Existing Linux TCP client The link between the router and client can be 1 mps (preferably larger) 1 mns * eg 0.3 * selected pause value / 8 = 40K bytes (ie 40 1K byte packets) buffer size. Sender and receiver window size of 64K bytes (preferably larger). Note: In this way, all packet drop (s) events always correspond exactly to the full buffer exhaustion scenario, and the 300ms “pause” is now well-reasonable (or, for example, very small) RTP-min (RTT) “pause” interval of triggering packet if buffer capacity is expanded = <300 ms.

  Finally, earlier test bed setups using IPCHAIN work in conjunction with not decrementing any CWND size without requiring any “pauses” ==> 100% link utilization, but not aggressive It is TCP friendly.

  “1. Existing Linux TCP is multiplicative to keep any CWND unchanged instead during congestion drop events (3 DUP ACKs halving CWND and RTO timeout resetting CWND to 1) When reducing CWND (CWND = CWND / 2 or CWND = 1 in case of RTO timeout), be sure to set the CWND value unchanged to half of the CWND value instead of being halved or “1” It must be ==> This in itself guarantees link utilization close to 100%, regardless of drop rate and RTT latency.

Receiver-based incremental deployment possible TCP friendly external Internet TCP
The modified receiver TCP source code can be modified directly (or similarly adapt the intercept monitor to do the same thing / do the same thing) and handle all existing RFC TCPs Even do.

  Overview (see also various previously described techniques t and subcomponent techniques) [Note: it is clear that no matter how large CWND size has been achieved, it does not cause congestion drops by itself. : The main cause of congestion packet (s) drop is “accelerated momentary increase” of CWND size, eg exponential increase or linear increase (return ACK-clocking rate...) .

  1. When the receiver TCP sends three DUP ACKs, it immediately completes a DUP ACK of a plurality of identical SEQNos of a derived number / series determined algorithmically (such a plurality of DUP ACKs of the same SEQNo. Can also be algorithmically controlled to control the sender TCP's CWND size, and thus the transmission rate as desired), so that the sender CWND size is half the time, eg, for fast retransmission 3DUP ACKs. Don't be fooled. . . Alternatively, it can be controlled with a defined CWND size timed increment according to detection by the receiver of the route congestion level (not congested / onset of some / exceeding buffer delay, congestion packet drop ... etc.) it can. Large window size, during packet arrival to detect packet drop early, receiver window size adjustment (eg, “0” to fully pause sender's effective window size transmission rate, therefore receiver window size is Now control the sender's effective window transmission rate instead of CWND). . . Etc. and can be combined with various previous techniques. The receiver can also use the sender's CWND size tracking method to help determine the multiple DUP ACK generation rate, so that the sender knows exactly which DUP ACK was received at the sender TCP. One byte data can be included in a generated ACK.

Or The receiver TCP suppresses the transmission of ACKs for some previously received SeqNo, so the sender TCP is now the receiver's rate of generation of multiple identical Seqno ACKs (derived algorithmically as desired). (Ie, sender's CWND size timed increment), so the receiver can control the sender's rate → effectively, sender TCP is now almost Always in fast retransmission mode. If a sufficiently large receiver and sender window size is negotiated, multiple DUP ACKs of one and the same SeqNo can transfer gigabytes to the end while staying in the DUP ACK of the same SeqNo series, Alternatively, SeqNo may be incremented to a larger (or maximum) SeqNo successfully received at any time prior to effective window size exhaustion (sender CWND) to “shift” the sender's window edge. Can be combined with technique (s) that keep the size always large enough).

And / or The receiver TCP never generates 3 DUP ACKs and only retransmits the sender RTO timeout (preferably an unacknowledged retransmission stopped before a longer RTO timeout period is triggered) A sufficiently large window-scaled size is negotiated to ensure that the sender's continuous retransmissions are not stopped by the sender), but the sender's CWND is reset to "0" or "1" upon RTO timeout The receiver needs this to ensure a fast exponential incremental recovery of the sender's CWND via multiple consecutive identical DUP ACKs after detecting an RTO timeout retransmission.
note:
. The router is smaller than the buffer. . . 50 ms etc. can be conveniently set (see the published Google search research report on the improved efficacy of such small buffer settings), and the RED mechanism can also be used, for example, for buffered packets ( One or more) can be adapted to for example discard the very first buffered packet of any flow (s) with residencies, eg real time transmission / TCP traffic on such internet subset Help achieve the input rate. TCP also simply rate throttles / "pauses" to immediately clear all buffering starts / appropriately reduce CWND size to enable clearing of all buffering starts be able to.

  . The above receiver TCP can preferably use a SACK field to convey a block of received SEqNos that exceed the “clamped” same SeqNo of a series of multiple DUP ACKs. Can also be used to convey occasional subsequent missing “gap” packets (RFC allows SACK 3 blocks and SACKed SEqNos are made unnecessary by existing RFC TCP. Not retransmitted).

  . The receiver TCP here is a “blocking SACK field” technique, a technique for generating a “timed” “clamped” SeqNo of a series of identical SeqNo DUP ACKs (thus, the sender's sliding to control the effective window size) Control the window Snd.UNA value and also control the number of multiple DUP ACKs of the same SeqNo generated to control the sender's CWND size), the technique of setting the receiver window size, tracking the sender's CWND size technique. . . And the receiver is congested, distinguishable by the beginning of the congestion / buffer depletion packet drop path (whether the OTT exceeds the min (OTT) recorded so far ...). Enable to control or “pause” the rate / effective window size / CWND size of the sender according to the monitoring by the receiver of the BER packet drop (s) during the period (not distinguishable).

Various notes . There are many different forms and various different combinations of possible described subcomponent methods that implement the desired changes in many different, perhaps even simpler ways. For example, to ensure PSTN-like transmission quality throughout the network / Internet subset (s) if all the TCPs in the network are all similarly changed, eg, the latest RTT (or where appropriate) OTT) —Every TCP sender simply “pauses” (or receiver-based TCP “pauses” sender TCP) for the recorded min (RTT) (or min (OTT) where appropriate) interval. It's very easy. Instead of the “pause” above, the modified TCP, for example, the available physical bandwidth capacity of all extra flight packets (link (s)) that may cause or require buffering. More can be dealt with without causing the beginning of buffering) (or simply reduce buffering by a certain level) and the total number of flight packets is immediately reduced as quickly as possible. To ensure that all subsequent unresolved flight packets now do not require buffering along the path (or simply reduce buffering by a certain level), for example Depending on the desired algorithm devised, its CWND size can be set to eg CWND * (latest RTT-min (RTT)) / latest of RTT or, for example, CWND * (latest RTT-min (RTT)) / min (RTT). . . Each can be reduced instead.

  . If all receiver TCPs in the network are all modified as described above, the receiver TCP is the desired algorithm devised. . . For example, all RTTs (or OTTs) of multiple DUP ACK rates as long as RTT (or OTT) remains below the current most recent recorded min (RTT) (or current most recent recorded min (OTT)) Multiplicative increase and / or linear increase. . . The same SeqNo series generation rate / spacing / temporary stop of multiple DUP ACKs. . . Can have complete control of the sender TCP transmission rate via overall complete control such as Further, if the RTT (or OTT) is greater than the current latest recorded min (RTT) (or the current latest recorded min (OTT), ie if the onset of congestion is detected, the receiver-based Modified TCP (or intercepting software / forwarding proxy, etc.) can be “paused” for an algorithmically devised period during which receiver-based modified TCP Match what is needed to match the new SeqNo packet (s) to be performed (ie, generate one DUP ACK for each incoming new SeqNo packet (s)) Except for this, the generation of additional extra DUP ACKs can be “frozen”, which It should allow reduction / clearing of total flight packets / prevention of buffering along the path.

  . The receiver-based TCP includes the ACKNo and SeqNo. . . Etc., using RTT / OTT / total flight packets. . . To help the receiver detect / calculate etc., it can include, for example, 1 byte of garbage data that is included in the “selected marked” DUP ACK (s).

November 21, 2005 Filing
Various refinements and notes
Incrementally deployable TCP friendly external Internet 100% link usage data storage transfer NextGenTCP :
At the top most level, CWND is now never reduced at all.

Using the Windows desktop “folder string search” facility, it is easy to locate every occurrence of a CWND variable in all subfolders / files. . . . . . To be complete when RTO is timed out. . . Even if the congestion induces, we do not decrement / reset CWND at all. . . . .
Our RTO timed out algorithm pseudo-code that changes the specification of the existing RFC should look like this (for the “actual congestion drop” indication):

Timeout: / * Multiplicative decrease * /
. recordedCWND = CWND (However, if another RTO timeout occurs during an ongoing “pause”, then the recorded CWND = recorded CWND!

  . ssthresh = cwnd (However, if another RTO timeout occurs during an ongoing “pause”, Stresh = recordedCWND! / * I don't want to accidentally pull down the STSresh size * /).

. Calculate “pause” interval, set CWND = “1 * MSS” and restore to CWND = recordedCWND after “pause” counts down;
Our RTO timed-out algorithm pseudo-code that changes the specification of an existing RFC should look like this (for a “non-congested drop” indication):

Timeout: / * Multiplicative decrease * /
ssthresh = sstresh;
CWND = CWND;
/ * Both are not changed! * /
It is only necessary to ensure that RFC TCP has changed according to these simple rules of thumb:
1. Never decrement any CWND value except to temporarily cause a “pause” on the “actual congestion” indication (and then restore CWND to recordedCWND). In the actual congestion indication (at the time of the third DUP ACK or RTO timeout-min (RTT)> for example, the latest RTT at 200 ms), the STSresh is pre-existing so that the subsequent CWND increment is additively linear Note that CWND needs to be set.

  2. In the case of non-congestion indication (3D DUP ACK or RTO Timeout-min (RTT) <e.g. Latest RTT at 200 ms), do not “pause” for both the fast retransmission module and the RTO timed out module, It does not allow any existing RFCs to change the CWND value or Sshsh value.

  The current pause in progress (which can only be triggered by an “actual congestion” indication), if present, must be allowed to proceed to countdown (fast retransmit module) And RTO timeout module).

  3. If there is already a current “pause” in progress, the subsequent intervening “actual congestion” indication will now completely end the current “pause” and begin a new “pause” (just The problem of setting / overwriting a new “pause” countdown value): For both the fast retransmission module and the RTO timeout module, the recordedCWND is now = recordedCWND (= not CWND) and now Stress = recordedCWND (not CWND) To manage.

Very simple basic working first version full specification: very few FREEBSD / LINUX TCP source code changes with very few lines [initially set very large initialized min (RTT) value = eg 30000ms Then continuously set min (RTT) = min (the RTT of the latest ACK to arrive, min (RTT))].
1.1 IF 3DUP ACK THEN
Latest Return ACK RTT at IF 3DUP ACK Fast Retransmission-Current Recorded min (RTT) = <eg 200ms (ie we can now say this packet drop could possibly be caused by a "congestion event" Therefore, do not unnecessarily set the CWND value in Stress.) THEN Do not change the CWND / SSResh value (ie, CWND = CWND / 2 as is currently done with existing fast retransmission RFCs). Or even set CWND / 2 to SSthrsh).

ELSE SSThresh must be set to be the same as this recorded existing CWND size (not CWND / 2 of the existing fast retransmission RFC). Instead of holding an existing CWND size record , Set CWND = “1 * MSS”, “pause” countdown global variable = minimum of the latest RTT-min (RTT), 300 ms of the packet that triggers the 3rd DUP ACK fast retransmission or triggers the RTO timeout Set the value .

  Note: Setting CWND value = 1 * MSS is just the first fast retransmission packet to allow TCP to clear buffered packets along the path before restarting transmission. Causes the desired temporary pause / stop of all forward forwarding of packets except the retransmit packet (s)].

ENDIF
ENDIF
1.2 After the “pause” time variable has counted down, restore the CWND to the previous recorded CWND value (ie, the sender can now resume normal transmission after the “pause” has ended). it can).

2.1 IF RTO timeout THEN
RTT of latest return ACK at IF RTO timed out-current recorded min (RTT) = <eg 200 ms (ie we now can't possibly cause this packet drop due to "congestion event" Therefore, know that the CWND value should not be unnecessarily reset to 1 * MSS) THEN Do not reset the CWND value to 1 * MSS and do not change the CWND value at all (ie, currently done with the existing RTO timeout RFC) Does not even reset CWND at all).

ELSE Instead, keep existing CWND size record, set CWND = “1 * MSS”, “pause” countdown global variable = (latest RTT-min (RTT) of packet at RTO timed out, A minimum value of 300 ms) must be set.

  Note: Setting CWND value = 1 * MSS will allow RTO timed out retransmission packets (to allow TCP to clear buffered packets along the path before resuming transmission. Cause a desired temporary pause / stop of all forward forwarding of packets (except one or more)].

  2.2 After the “pause” time variable has counted down, restore the CWND to the previous recorded CWND value (ie, the sender can now resume normal transmission after the “pause” has ended). it can).

  This is the end! .

Background material . The most recent RTT of the packet that triggers the third DUP ACK fast retransmission or triggers the RTO timeout is readily available from variables maintained in the existing Linux TCB for the last measured round trip time RTT. The minimum recorded min (RTT) is only readily available from variables maintained in the existing Westword / FastTCP / Vegas TCB, but min (RTT) = [min (RTT), last measurement It should be simple enough to write 2-3 lines of code that continually update the minimum value of] of the round-trip time RTT that has been made. Reference: http: // www. cs. umd. edu / ~ shankar / 417-Notes / 5-note-transportContControl. http: RTT variable maintained by Linux TCB <http: // www. scit. wlv. ac. uk / rfc / rfc29xx / RFC2988. html>: RTO calculation Google Search term “tcp rtt variables” <http: // www. psc. edu / networking / perf_tune. html>: Linux TCP RTT Parameter Tuning Google Search: “Linux TCP minimum recorded RTT” or “Linux tcp minimum recorded rt variable” Note: TCP West is the minimum to measure the RT.
note:
1. The above-mentioned “congestion notification trigger event” may alternatively be the latest RTT-min (RTT)> = specified interval, eg 5 ms / 50/300 ms ms. . . (Corresponding to the delay introduced by the buffering experienced on the pure non-congested RTT or its estimated min (RTT) and along the path beyond it, rather than a packet drop indication event) .

  2. Once the “pause” triggered by the actual congestion drop (s) indication has finished counting down, the above algorithm / scheme is adapted so that CWND now has this momentary “pause”. Ensure that a value equal to the total number of outstanding flight packets at the counted down time (ie, the latest maximum forwarded SeqNo-equal to the latest maximum return ACKNo) is set → Should be prevented from being generated by the source TCP. This is because during the “pause” period, there may be a large number of received back ACKs that may have advanced the edge of the sliding window very substantially.

  Also, as an alternative to many possible ones, CWND initially received an unmodified CWND (“1 * MSS” in the third DUP ACK fast retransmission request that triggers a “pause” countdown. ) Or exactly equal to the total number of unresolved flight packets at this moment, and this momentary total number of unresolved flight packets [optionally] when the “pause” has finished counting down. Subtract the total additional SeqNo multiple DUP ACKs (beyond the first 3 DUP ACKs that trigger fast retransmission) received before “pause” counts down at this momentary “pause” counted downtime (ie, , Exactly the latest maximum transferred SeqNo at this moment-equal to the latest maximum return ACKNo)]] → The modified TCP can now stroke out new packets corresponding to each additional multiple same SeqNo DUP ACK received during the “pause” interval to the network. , If CWND is now restored to a value equal to the total additional SeqNo multiple DUP ACKs received during the “pause” minus the current total momentary unresolved flight packets when the “pause” has finished counting down In addition, the transmission rate can optionally be “slowed down” after the “pause” has counted down to delay intervening buffering along the path.

  Another possible example is that CWND was initially set to “1 * MSS” on the 3rd DUP ACK fast retransmission request that triggered the “pause” countdown, and then “pause” has finished counting down. Sometimes, this momentary total unresolved flight packet count minus the total addition is to restore to the same value as the same SeqNo multiple DUP ACK → In this way, when the “pause” counts down, the modified TCP will send a new packet Rather than “burst” out, it simply initiates a stroke out of the new packet corresponding to the subsequent new return ACK rate into the network.

3. The minimum value of the “pause” countdown global variable = (the most recent RTT-min (RTT), 300 ms) of the packet that triggers the third DUP ACK fast retransmission or triggers the RTO timeout of the above algorithm / scheme is: Instead, the minimum value of = (latest RTT-min (RTT), 300 ms, max (RTT)) of the packet that triggers the third DUP ACK fast retransmission or triggers the RTO timeout can be set, where , Max (RTT) is the maximum RTT observed so far. This inclusion of max (RTT) allows the “pause” period to be specified, for example, even in very unlikely situations where the buffer capacity of the node is extremely small (eg, within a LAN or even within a WAN). This is to ensure that the set 300 ms value is not set too large. Also, instead of 300 ms in the above example, this value can instead be dynamically algorithmically derived for different paths.

  4). A simple method that allows simple widespread implementation of a ready guaranteed service enabled network (or just a network without congestion drop and / or just a network with much less buffering delay) Change / software upgrade all (or almost all) routers and switches in one node to instantly generate the entire three DUP ACKs to the source of the traversing TCP flow and When a node starts buffering packets for a TCP flow that does (ie, the forwarding link is now 100% busy and the packets of the source of the traversing TCP flow as a total begin to be buffered) Decrease rate It should be that shown in Suyo. Instead, 3DUP ACK generation is performed, for example, at a usage level at which a link to be transferred is specified, for example, 95% / 98%. . . Or when some other specified trigger condition is reached. It does not matter whether the packets corresponding to the three pseudo DUP ACKs are actually received correctly at the destination. This is because a subsequent ACK from the destination to the source corrects this.

  The fields of the three generated DUP ACK packets include the minimum required source address, destination address, and SeqNo (this checks the currently buffered packet (s) 3 Can be easily obtained by taking care that the ACK field of two pseudo-DUP ACKs is obtained / derived from the ACKNo of the inspected buffered packet). However, the ACKZNo field of the pseudo three DUP ACKs is the maintenance of the latest maximum ACKNo generated by the destination TCP of the particular unidirectional source / destination TCP flow (s), eg switch / router. Or alternatively, the switch / router first waits for the destination-to-source packet to arrive at the node and then returns the packet From examining the ACK field, the ACKNo field of the three pseudo DUP ACKs can be obtained / or derived.

  Similar to the above scheme, existing RED and ECN. . . As well as having a modified algorithm as outlined above to enable a real-time guaranteed service enabled network (or a network with no congestion drop and / or much less buffer delay). be able to.

5. Another variant on Windows:
First, the module takes over all fast retransmissions / RTO timeouts from MSTCP, ie MSTCP never sees any DUP ACK or RTO timeouts: the module simply acknowledges from MSTCP Spoof all intercepted new packets (only later: if necessary, send MSTCP a "0" window size update or change the window size field of the incoming network packet to "0" Pause / slow down MSTCP packet generation: during congestion notification, eg 3DUP ACK or RTO timeout). The module builds a list of SeqNo / packet copy / system (clearly ordered by SeqNo) of all forwarded packets and performs fast retransmission / RTO retransmission from this list. All items on this list with SeqNo <current largest received ACK are removed, and all SeqNo SACKed are also removed.

  Remember also that this module needs to incorporate "SeqNo Wrap Around" protection and "Time Wrap Around" protection.

  By spoofing the acknowledgment of all intercepted MSTCP outgoing packets, our Windows software now does not require any modification of any incoming network packets to MSTCP. . . MSTCP simply ignores all 3 received DUP ACKs already out of the sliding window (already acknowledged!) And does not send timed out packets (already acknowledged) In addition, we now change the receiver window size field. . . Etc., the MSTCP packet generation rate can be easily controlled at any time. The software emulates MSTCP's own Windows increment / congestion control / AIMD mechanism by allowing the maximum value of the flight packet to be equal to the emulated / tracked MSTCP CWND size at any given time. As an example of the outline outline (among many possible ones), this is, for example, for each return ACK, the emulated / tracked pseudo-mirror CWND size is 3DUP ACK fast retransmission Is doubled within each RTT when there is not yet, but if a 3DUP ACK fast retransmission occurs, the emulated / tracked pseudo-mirror CWND size is now incremented by 1 * MSS per RTT Can be achieved by assuming that The software allows the maximum number of instantaneous total outstanding flight packets to not exceed the emulated / tracked pseudo CWND size and “pauses” the MSTCP transmission when it exceeds the pseudo CWND size. It should only throttle MSTCP packet generation via a 0 "receiver window size update / change the receiver window size of incoming packets to" 0 ".

  The window software then uses the latest largest forwarded MSTCP packet SeqNo and the latest largest network incoming packet ACKNo (the difference is quite unresolved which corresponds quite well to the MSTCP CWND value). By keeping track of (giving the total number of flight packets), it can always be estimated whether the MSTCP CWND size is stored. If the window software here is the total number of flight packets> = the CWND estimate described above (or alternatively, the above CWND estimate and the effective window size derived from RWND and / or SWND) For example, it is only necessary to reliably stop “automatic spoofing of ACK” to MSTCP.

Claims (14)

  A method for improving TCP and / or TCP-like protocols and / or other protocols, when a congestion event such as a congestion packet drop is detected and / or a return ACK round trip time RTT / one-way trip time OTT Sending a sender's data when it approaches or exceeds some threshold, such as a non-congested RTT / OTT of the flow path or a known value of its latest available best estimate min (RTT) / min (OTT) To avoid and / or prevent and / or recover from network congestion via full or partial “pauses” / “pauses”. A method for improving TCP and / or TCP-like protocols and / or other protocols, wherein (a) to (c), ie:
(A) New realization that TCP's sliding window mechanism “effective window” and / or congestion window CWND does not need to be reduced in size to avoid and / or prevent and / or recover from congestion Make good use of techniques,
(B) When congestion events such as congestion packet drop are detected and / or return ACK round trip time RTT / one-way trip time OTT is, for example, flow path non-congested RTT / OTT or its latest available best Via a complete or partial “pause” / “pause” of the sender's data transmission when it approaches or exceeds some threshold, such as a known value of min (RTT) / min (OTT) Instead, congestion is avoided and / or prevented and / or recovered from,
(C) not or instead of (b) above, or in combination with it, the “valid window” and / or congestion window CWND value of the TCP sliding window mechanism returns the latest return when congestion is detected. Round trip time RTT / one-way trip time OTT value and / or known non-congested round trip time RTT / one-way trip time OTT value for a particular flow path or its latest available best estimate min ( RTT) / min (OTT) and / or algorithmically depending at least in part on the latest observed longest round trip time max (RTT) / one-way trip time max (OTT) of a particular flow path A method that includes any combination / subset of reduced to a derived value. A method of data communication network / Internet / Internet subset / proprietary Internet segment / WAN / LAN (hereinafter referred to as a network) that is virtually free of a guaranteed service, and features (a) to (f), namely:
(A) all packets / data units sent from a source in the network and arriving at a destination in the network all arrive without a single packet being discarded due to network congestion;
(B) applies only to all packet / data units that require guaranteed service functionality;
(C) the packet / data unit traffic is intercepted and processed before being forwarded;
(D) The transmitting source or traffic sources are intercepted and processed and forwarded and / or the packet / data unit traffic is intercepted at the originating transmitting source or sources. Only processed forward and sent forward,
(E) The existing TCP / IP stack at the sending source and / or the receiving destination does not require the use of existing QoS / MPLS techniques, and any of the switch / router software in the network is end-to-end. Any source in the network that does not need to be changed or contributed to achieve end performance results, and does not require the provision of unrestricted bandwidth on every inter-node link in the network / Changed to achieve the same end-to-end performance results between the destination node pair;
(F) Most of the traffic in the network consists of TCP traffic, and UDP / ICMP. . . Other traffic types do not exceed the total available bandwidth of any of the one or more inter-node links in the network at any time, and applications that generate other traffic types can always If the total available bandwidth of any one or more of the inter-node links is not exceeded, UDP / ICMP. . If other traffic types exceed the total available bandwidth of any of one or more inter-node links in the network at any given time, one or more affected in the network Only source / destination node-to-traffic traversing multiple inter-node links will not necessarily be guaranteed to be virtually congested and guaranteed service during this time and / or transmitted from a source in the network All packets / data units arriving at a destination within are not necessarily all arriving, that is, with any combination / subset with one or more packets being discarded due to network congestion Method.   4. The method according to any one of claims 1 to 3, wherein in the method, the protocol improvement / change is effected in a sender TCP.   4. The method according to any one of claims 1 to 3, wherein the protocol improvement / change is effected at a receiver-side TCP.   4. A method as claimed in any preceding claim, wherein the protocol improvement / change is effected at a switch / router node of the network.   A method wherein the protocol improvement / change is effected at any combination of locations specified in any one of claims 4-6.   7. A method wherein said protocol improvement / modification is effected at any combination of positions specified in any one of claims 4 to 6, wherein said method comprises an existing "random early detection" RED and / or " Method in which the "explicit congestion notification" ECN is modified / adapted to give the effect disclosed in any one of claims 1-7.   9. The switch / router in the network is adjusted in its configuration or set-up or operation, for example buffer size adjustment, to give the effect disclosed in any one of claims 1-8. The method of any one of these. In said method,
. The existing protocol RFC temporarily causes the sender's CWND value to temporarily “pause” / “stop” the sender's data transmission upon detected congestion (eg, temporarily during “pause” / “stop”). After the sender's CWND = 1 * MSS is set and the "pause" / "stop" is complete, the sender's CWND value is, for example, an existing CWND value before the "pause" / stop, or some algorithmically derived value Is changed so that none is decremented / decremented at any time, except that the "pause" / "stop" interval is set to any 300ms, for example , Minimum (the latest RTT of the return ACK packet that triggers the 3rd DUP ACK fast retransmission, or the latest RTT, 300 ms) or the like, or the latest RTT of the return ACK packet that triggers the third DUP ACK fast retransmission or the latest RTT of the return ACK packet when the RTO times out (300 ms, max ( RTT)) etc. can be derived algorithmically,
And / or. The existing protocol RFC is modified so that SSThresh is instead set to the existing CWND value before congestion detection that now triggers “pause” / “stop”, ie, the subsequent CWND increment is CWND The method according to any one of claims 1 to 9, which is only linear additive beyond the value.   In the method, if the congestion detection is due to non-congestion drops, eg physical transmission errors, ie BER, ie not due to congestion packet drops, the “pause” / “stop” countdown interval is instead “ 0 is set, ie the actual “pause” / “stop” of the data transmission is not started, and all pre-existing current “pauses” / “stop” in progress are counted down Note that it is normally allowed to proceed, congestion detection is the latest returned when the 3rd DUP ACK triggers a fast retransmission, for example, the latest returned ACK RTT or RTO timed out. 11. If the ACK RTT-min (RTT) <200 ms, for example, it can be attributed to a reason other than congestion. The method described.   In the method, if there is already a current “pause” / “stop” in progress, the subsequent “actual” congestion event display now extends the current “pause” / “stop” interval. Simply count the current “pause” / “stop” countdown, eg, Minimum (latest RTT of return ACK packet that triggers 3rd DUP ACK fast retransmission, or latest RTT of return ACK packet when RTO times out, 12. A method according to claim 10 to 11, wherein a new value such as 300 ms, max (RTT)) is set / overwritten. In said method,
The node starts buffering the packets of the traversing TCP flow (ie, the forwarding link is now 100% utilized and the “source” packets of the traversing TCP flow as a total begin to be buffered) A router of a node in the network that must be modified / software upgraded to instantly generate a whole of three DUP ACKs to the source of the traversing flow to indicate to the source to reduce the transmission rate sometimes And any one or all or almost all of the switches: the generation of the three DUP ACKs may instead be performed, for example, if the forwarding link has a specified utilization level, eg 95% / 98% . . . 13. A method according to any one of the preceding claims, which can be triggered when a certain other trigger condition is reached or the like. In said method,
Existing REDs and ECNs are similarly modified in their algorithms as outlined in the principles and methods contained in any one of claims 1 to 13 to provide real-time guaranteed service enabled networks (or congestion drops) 14. A method according to any one of claims 1, 2, 7, and 9 to 13, which enables a network with no and / or much less buffer delay.