WO2006056880B1

WO2006056880B1 - Immediate ready implementation of virtually congestion free guaranteed service capable network: external internet nextgentcp (square wave form) tcp friendly san

Info

Publication number: WO2006056880B1
Application number: PCT/IB2005/003580
Authority: WO
Original assignee: Individual
Current assignee: Individual
Priority date: 2004-11-29
Filing date: 2005-11-29
Publication date: 2006-09-28
Anticipated expiration: 2007-05-29
Also published as: AP2007004044A0; WO2006056880A8; AU2005308530A1; CA2589161A1; EP1829321A2; WO2006056880A2; KR20070093077A; WO2006056880A3

Abstract

Various techniques of simple modifications to TCP/IP protocol & other susceptible protocols and related network's switches/routers configurations, are presented for immediate ready implementations over external Internet of virtually congestion free guaranteed service capable network, without requiring use of existing QoS/ MPLS techniques nor requiring any of the switches/routers softwares within the network to be modified or contribute to achieving the end-to-end performance results nor requiring provision of unlimited bandwidths at each and every inter-node links within the network.

Claims

202

AMENDED CLAIMS

[received by the International Bureau on 17 July 2006 (17.07.06) original claims 1-14 replaced by new claims 1-14]

Methods for improving TCP &/or TCP like protocols &/or other protocols , which could be capable of completely implemented directly via TCP/ Protocol stack software modifications without requiring any other changes/ re-configurations of any other network components whatsoever and which could enable immediate ready guaranteed service PSTN transmissions quality capable networks and without a single packet ever gets congestion dropped, said methods avoid &/or prevent &/or recover from network congestions via complete or partial 'pause' / 'halt' in sender's data transmissions when congestion events are detected such as congestion packet drops &/or returning ACK' s round trip time RTT / one way trip time OTT comes close to or exceeded certain threshold value eg known value of the flow path's uncongested RTT / OTT or their latest available best estimate min(RTT) / min(0TT).

2. Methods for improving TCP &/or TCP like protocols &/or other protocols , which could be capable of completely implemented directly via TCP/ Protocol stack software modifications without requiring any other changes/ re-configurations of any other network components whatsoever and which could enable immediate ready guaranteed service PSTN transmissions quality capable networks and without a single packet ever gets congestion dropped, said methods comprises any combinations/ subsets of (a) to (c) :

(a) makes good use of of new realization/ technique that TCP's Sliding Window mechanism's ' Effective Window ' &/or Congestion Window CWND needs not be reduced in size to avoid &/or prevent &/or recover from congestions.

(b) Congestions instead are avoided &/or prevented &/or recovered from via complete or partial 'pause'/ 'halt' in sender's data transmissions when congestion events are detected such as congestion packet drops ScI or returning ACK' s round trip time RTT / one way trip time OTT comes close to or exceeded certain threshold value eg known value of the flow path's uncongested RTT / OTT or their latest available best estimate min(RTT) / min(OTT).

(c) Instead or in place or in combination with (b) above, TCP's Sliding Window mechanism's ' Effective Window ' &/or Congestion Window CWND value is reduced to a value algorithmically derived dependent at least in part on latest returned round trip time RTT / one way trip time OTT value when congestion is detected , and/or the particular flow path's known uncongested round trip time RTT / one way trip time OTT or their latest available best estimate min(RTT)/ min(OTT) , and/ or the particular flow path's latest observed longest round trip time max(RTT) / one way trip time max(OTT)

3. Methods for virtually congestion free guaranteed service capable data communications network/ Internet/ Internet subsets/ Proprietary Internet segment/W AN/LAN [ hereinafter refers to as network] with any combinations/ subsets of features (a) to(f) :

(a) where all packets/data units sent from a source within the network arriving at a destination within the network all arrive without a single packet being dropped due to network congestions.

(b) applies only to all packets/ data units requiring guaranteed service capability.

(c) where the packet/ data unit traffics are intercepted and processed before being forwarded onwards . 204

(d) where the sending source/ sources traffics are intercepted processed and forwarded onwards, and/or the packet/ data unit traffics are only intercepted processed and forwarded onwards at the originating sending source/ sources .

(e) where the existing TCP/IP stack at sending source and/or receiving destination is/are modified to achieve the same end-to-end performance results between any source-destination nodes pair within the network, without requiring use of existing QoS/MPLS techniques nor requiring any of the switches/routers softwares within the network to be modified or contribute to achieving the end- to-end performance results nor requiring provision of unlimited bandwidths at each and every inter-node links within the network .

(f) in which traffics in said network comprises mostly of TCP traffics, and other traffics types such as UDP/ICMP... etc do not exceed, or the applications generating other traffics types are arranged not to exceed, the whole available bandwidth of any of the inter- node link/s within the network at any time, where if other traffics types such as

UDP/ICMP.. do exceed the whole available bandwidth of any of the inter- node link/s within the network at any time only the source-destination nodes pair traffics traversing the thus affected inter- node link/s within the network would not necessarily be virtually congestion free guaranteed service capable during this time and/or all packets/data units sent from a source within the network arriving at a destination within the network would not necessarily all arrive ie packet/s do gets dropped due to network congestions.

4. Methods in accordance with any of Claims 1 - 3 above, in said methods the improvements / modifications of protocols is effected at the sender TCP.

5. Methods in accordance with any of Claims 1 - 3 above, in said methods the improvements / modifications of protocols is effected at the receiver side TCP. 205

6. Methods in accordance with any of Claims 1 - 3 above, in said methods the improvements / modifications of protocols is effected in the network's switches/ routers nodes.

7. Methods where the improvements / modifications of protocols is effected in any combinations of locations as specified in any of the Claims 4 - 6 above.

8. Methods where the improvements / modifications of protocols is effected in any combinations of locations as specified in any of the Claims 4 - 6 above, in said methods the existing ' Random Early Detect ' RED &/or ' Explicit Congestion Notification ' ECN are modified/ adapted to give effect to that disclosed in any of the Claims 1 - 7 above.

9. Methods in accordance with any of the Claims 1 - 8 above or independently , where the switches/ routers in the network are adjusted in their configurations or setups or operations , such as eg buffer size adjustments, to give effect to that disclosed in any of the Claims 1 - 8 above.

10. Methods in accordancewith any of Claims 1 - 9 above, in said methods :

. existing protocols RFCs are modified such that sender's CWND value is instead now never reduced / decremented whatsoever , except to temporarily effect ' pause ' / ' halt ' of sender's data transmissions upon congestions detected ( eg by temporarily setting sender's CWND = 1 * MSS during ' pause ' / ' halt ' & after ' pause ' / ' halt ' completed to then restore sender's CWND value to eg existing CWND value prior to ' pause ' / halt or to some algorithmically derived value ) : the ' pause ' / halt ' interval could be set to eg arbitrary 300ms or algorithmically derived such as Minimum( latest RTT of returning ACK packet triggering the 3^rd DUP ACK fast retransmit OR latest RTT of returning ACK packet when RTO Timedout , 300ms ) or algorithmically derived such as Minimum( latest RTT of returning ACK packet triggering the 3^rd DUP ACK fast retransmit OR latest RTT of returning ACK packet when RTO Timedout , 300ms , max(RTT) ) 206

AND/OR

. existing protocols RFCs are modified such that SSThresh is instead now set to existing CWND value prior to the congestion detection which triggers ' pause ' / ' halt ' , ie subsequent CWND increments would only be linear additive beyond CWND value

11. Methods as in accordance with Claim 10 above , in said methods if the congestion detection is due to non-congestion drops eg physical transmission errors or BER ie not due to congestion packet drops, then the ' pause ' / ' halt ' count down interval will be set to ' 0 ' instead, ie no actual ' pause ' / ' halt ' of data transmissions will be initiated, also note that any pre-existing current ' pause ' / 'halt ' in progress will be allowed to progress normally onto counteddwon : congestion detection could be attributable to non-congestion reasons if eg latest returned ACK' s RTT when 3^rd DUP ACK triggering fast retransmit or latest returned ACK's RTT when RTO Timedout - min(RTT) < eg 200 ms

12. Methods as in accordance with Claims 10 - 11 above, in said methods if there is already a current ' pause ' / ' halt ' in progress, a subsequent ' real ' congestion event indication will now extends the current ' pause ' / ' halt ' interval, a matter of merely setting/ overwriting the present ' pause ' / ' halt ' countdown to a new value such as eg Minimum( latest RTT of returning ACK packet triggering the 3^rd DUP ACK fast retransmit OR latest RTT of returning ACK packet when RTO Timedout , 300ms , max(RTT) )

13 .Methods as in accordance with any of Claims 1 - 12 above , in said methods : any one , or all or almost all routers & switches at a node in the network to be modified/ software upgraded to immediately generate total of 3 DUP ACKs to the traversing flows' sources to indicate to the sources to reduce their transmit rates when the node starts to buffer the traversing TCP flows' packets ( ie forwarding link now is 100% utilised & the aggregate traversing TCP flows' sources' packets start to be buffered ) :the 3 DUP 207

ACKs generation may alternatively be instead triggered eg when the forwarding link reaches a specified utilisation level eg 95% / 98%... etc, or some other trigger conditions specified

14. Methods as in accordance with any of Claims 1, 2, 7 , 9- 13 above , in said methods : existing RED & ECN could similarly have their algorithm modified as outlined in the principles & schemes contained in any of the Claims above, enabling real time guaranteed service capable networks ( or non congestion drops, &/or much much less buffer delays networks ).