WO2008112456A1

WO2008112456A1 - Method and apparatus for handling interconnection transmissions

Info

Publication number: WO2008112456A1
Application number: PCT/US2008/055747
Authority: WO
Inventors: Yuri Granovsky; Uri Kogan; Itai Shaby; Michael Spivak
Original assignee: Motorola, Inc.
Priority date: 2007-03-14
Filing date: 2008-03-04
Publication date: 2008-09-18
Also published as: GB0704825D0; GB2447469A; GB2447469B

Abstract

A method of handling interconnection transmissions comprises the steps of: receiving a transmission from a peer; ascertaining whether the peer from which the transmission was received is adapted to perform transmission loss assessment; and if the peer is not adapted to perform transmission loss assessment, to implement transmission loss assessment on behalf of the peer.

Description

METHOD AND APPARATUS FOR HANDLING INTERCONNECTION

TRANSMISSIONS

TECHNICAL FIELD

The technical field relates generally to a method and apparatus for handling interconnection transmissions. In particular, the technical field relates to a system, a method and apparatus for handling interconnection transmissions to/from a local peer, and performing transmission loss assessment more efficiently.

BACKGROUND

It is known for a device to be connected to, the World Wide Web (www) , or other network, by way of a split connection (SC) host. An example of such a scenario might be a mobile device, such as a mobile telephone handset, connecting to the World Wide Web via a wireless network base station.

FIG. 1 illustrates an example of a known split connection arrangement 100. A first communication device 110, denoted as peer A, is able to connect to a second device 120, denoted as peer B, by way of a network 130, such as the World Wide Web. Peer A 110 connects to the network 130 by way of a split connection (SC) host 140. In this manner, peer A 110 is a ^λlocal' peer of the SC host 140. For the illustrated embodiment, peer B 120 connects to the network 130 directly, and is a ^λforeign' peer of the SC host 140. However, it will be appreciated by a skilled artisan that peer B 120 may also be connected to the network 130 by way of an SC host, or other intermediate device.

Devices communicate across networks by way of protocols, the protocols acting as a set of rules governing how information, data, etc. is to be sent and/or received. The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite has become the de facto standard for computer communications in today's networked world. The TCP/IP protocol suite is so named for two of its most important protocols:

Transmission Control Protocol (TCP) and Internet Protocol

(IP) . Another name for it is the Internet Protocol Suite, which is the phrase used in official Internet standards documents . As will be appreciated by a skilled artisan, a problem encountered when transmitting data is that of network congestion. To overcome this problem, various TCP congestion algorithms are known. TCP congestion algorithms prevent a sender from over-running the capacity of the network (for example, slower WAN links) . Several congestion control enhancements have been suggested and added to TCP over the years. This is still an active and ongoing research area, but modern implementations of TCP contain four intertwined algorithms as basic Internet standards:

• Slow start

• Congestion avoidance

• Fast retransmit

• Fast recovery Slow start

Old implementations of TCP would start a connection with the sender injecting multiple segments, or packets, into the network, up to the window size advertised by the receiver. While this is acceptable when the two peers are on the same local area network (LAN) , if there are routers and slower links between the sender and the receiver, problems can arise. Some intermediate routers cannot handle the number of segments transmitted, packets are dropped, resulting in re-transmissions and performance is consequently degraded.

The algorithm to avoid this problem is called ^λslow start' . It operates by observing that the rate at which new packets should be injected into the network is the rate at which the acknowledgments are returned by the receiving end. Slow start adds another window to the sender's TCP: the congestion window, called ^λcwnd/ . When a new connection is established with a peer on another network, the congestion window is initialized to one segment (for example, the segment size announced by the other end, or the default, typically 536 or 512) . Each time an acknowledgement (ACK) is received, the congestion window is increased by one segment. The sender can transmit the lower value of the congestion window or the advertised window. The congestion window (cwnd) is flow control imposed by the sender, while the advertised window is flow control imposed by the receiver. The former is based on the sender's assessment of perceived network congestion; the latter is related to the amount of available buffer space at the receiver for this connection . The sender starts by transmitting one segment and waiting for its ACK. When that ACK is received, the congestion window is incremented from one to two, and two segments can be sent. When each of those two segments is acknowledged, the congestion window is increased to four. This provides an exponential growth, although it is not exactly exponential, because the receiver may delay its ACKs, typically sending one ACK for every two segments that it receives. At some point, the capacity of the IP network (for example, slower wide area network (WAN) links) can be reached, and an intermediate router will start discarding packets. This tells the sender that its congestion window has become too large.

Congestion avoidance

The assumption of the congestion avoidance algorithm is that packet loss caused by errors is very small (for example much less than 1 percent) . Therefore, the loss of a data packet signals congestion somewhere in the network between the source and destination communication devices. There are two indications of packet loss:

1. A timeout occurs.

2. Duplicate ACKs are received. Congestion avoidance and slow start are independent algorithms with different objectives. But when congestion occurs TCP must slow down its transmission rate of packets into the network, and invoke slow start to reinitialise transmissions. In practice, they are implemented together.

Congestion avoidance and slow start require that two variables be maintained for each connection: • A congestion window, ^λcwnd/ ; and

• A slow start threshold size, ^λssthresh'

The known combined algorithm operates as follows: 5 1. Initialization for a given connection sets ^λcwnd' to one segment and ^λssthresh' to, for example 65535 bytes .

2. The TCP output routine never sends more than the lower value of ^λcwnd' or the receiver's advertised

I^ window.

3. When congestion occurs (timeout or duplicate ACK), one-half of the current window size is saved in λssthresh' . Additionally, if the congestion is indicated by a timeout, ^λcwnd' is set to one

15 segment.

4. When new data is acknowledged by the receiving end, increase ^λcwnd' , but the way it increases depends upon whether TCP is performing slow start or congestion avoidance. If ^λcwnd' is less than or 0 equal to ^λssthresh' , TCP is in slow start; otherwise, TCP is performing congestion avoidance.

Slow start continues until TCP is halfway to where it was being transmitted when congestion occurred (since it recorded half of the window size that caused the 5 problem in step 2), and then congestion avoidance takes over. Slow start has ^λcwnd' begin at one segment, and incremented by one segment every time an ACK is received.

As mentioned earlier, this opens the window exponentially: send one segment, then two, then four, and

30 so on.

Congestion avoidance dictates that ^λcwnd' be incremented by segsize*segsize/cwnd each time an ACK is received, where segsize is the segment size and ^λcwnd' is maintained in bytes. This is a linear growth of ^λcwnd' , compared to slow start's exponential growth. The increase in ^λcwnd' should be at most one segment each round-trip time (regardless of how many ACKs are received in that round trip time) , whereas slow start increments ^λcwnd' by the number of ACKs received in a round-trip time .

Fast re-transmit

Fast re-transmit avoids having TCP wait for a timeout to resend lost segments.

TCP may generate an immediate acknowledgment (a duplicate ACK) when an out-of-order segment is received. This duplicate ACK should not be delayed. The purpose of this duplicate ACK is to let the other end know that a segment was received out of order, and to inform the other end what sequence number is expected.

Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a re-ordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the re-ordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, this provides a strong indication that a segment has been lost. TCP then performs a re-transmission of what appears to be the missing segment, without waiting for a re- transmission timer to expire. Fast recovery

After fast re-transmit sends what appears to be the missing segment, congestion avoidance, without slow start, is performed. This is the fast recovery algorithm.

5 It is an improvement that allows high throughput under moderate congestion, especially for large windows.

The reason for not performing slow start in this case is that the receipt of the duplicate ACKs tells TCP more than just a packet has been lost. Since the receiver

10 can only generate the duplicate ACK when another segment is received, that segment has left the network and is in the receiver's buffer. That is, there is still data flowing between the two ends, and TCP does not want to reduce the flow abruptly by going into slow start. The

15 fast re-transmit and fast recovery algorithms are usually implemented together as follows:

1. When the third duplicate ACK in a row is received, set ssthresh to one-half the current congestion window, ^λcwnd' , but no less than two segments. Re-

™ transmit the missing segment. Set ^λcwnd' to λssthresh' plus three times the segment size. This inflates the congestion window by the number of segments that have left the network and the other end has cached (i.e. three, since this is the number

25 of duplicate ACKs received) .

2. Each time another duplicate ACK arrives, increment λcwnd' by the segment size. This inflates the congestion window for the additional segment that has left the network. Transmit a packet, if allowed

~>v by the new value of ^λcwnd' .

3. When the next ACK arrives that acknowledges new data, set ^λcwnd' to ^λssthresh' (the value set in step 1) . This ACK should be the acknowledgment of the retransmission from step 1, one round-trip time after the re-transmission. Additionally, this ACK should acknowledge all the intermediate segments sent between the lost packet and the receipt of the first duplicate ACK. This step is congestion avoidance, since TCP is down to one-half of the rate it was at when the packet was lost . In the Internet, packets are often transmitted in bursts (due to the bursty nature of TCP etc) . As a result, losses also often happen within and between bursts. This is primarily due to first-in first-out

(FIFO) queues in routers. A fundamental problem is that Fast Re-transmit assumes that only one segment was lost. This can result in loss of ACK clocking and timeouts if more than one segment is lost.

Furthermore, several problems are encountered with multiple packet losses in a window of data (usually in the order of half a window) . For example, Fast Retransmit and Fast Recovery are invoked several times in succession leading to multiplicative decreases of ^λcwnd' and ^λssthresh' - impacting the throughput of the connection. Another problem encountered is known as "ACK starvation": this happens due to the ambiguity of duplicate ACKs and due to the dynamics of ^λcwnd' . Upon initially receiving duplicate ACKs, the sender sets ^λssthresh' to half ^λcwnd' , and reduces ^λcwnd' to equal ^λssthresh' plus three times the segment size. With the continual receipt of duplicate ACKs, the sender increases ^λcwnd' so that it sends new packets until it fills the advertised window size (i.e. that set by the receiver).

Upon receipt of a non duplicate ACK, the sender reduces the window size to equal to ^λssthresh' (i.e. half its previous size prior to the receipt of the duplicate ACKs) .

However, due to multiple packet losses, this non duplicate ACK will be followed by three duplicate ACKs, signaling that another segment was lost. Thus, the sender again sets ^λssthresh' to half ^λcwnd' (potentially a quarter of the original size of ^λcwnd' ) , and reduces ^λcwnd' to equal ^λssthresh' plus three times the segment size. With the continual receipt of duplicate ACKs, the sender increases ^λcwnd' so that it sends new packets until it fills the advertised window size (i.e. that set by the receiver) . Upon receipt of a non duplicate ACK, the sender reduces the window size to equal to ^λssthresh' (i.e. potentially a quarter of its previous size prior to the receipt of the initial duplicate ACKs) .

If this happens several times in succession, the left edge of the sending window advances only after each successive non-duplicate ACK, and the amount of data in flight (sent, but not yet ACK' d) eventually becomes more than the congestion window (successively halved by each invocation of Fast Re-transmit) . As there are no more ACKs to receive, the sender stalls and recovers from this dead-lock only through a timeout - which causes a slow start .

To overcome these problems, various TCP optimisation algorithms have been implemented. The purpose of TCP optimisation is to distinguish between random packet loss and network congestion. If a data packet is not received (or more appropriately the acknowledgement of a data packet is not received) due to random packet loss, then it is assumed to be better to resend the lost packet without reducing the window size. In this way, the transmission rate is not unduly reduced. Conversely, when a data packet is lost due to network congestion

(i.e. the packet has been dropped by a router etc.), the window size should be reduced in order to free up network bandwidth.

One such known TCP optimisation implementation is TCP Westwood, which aims to enhance congestion control by way of Fair Share Estimates (FSE) . The sender calculates FSEs by sampling inter-arrival times of ACKs, and information provided within/by the ACKs about the number of bytes delivered. The FSE is then used by the sender to appropriately set ^λcwnd' and ^λssthresh' after packet loss, as indicated by three duplicate ACKs or a timeout.

FSE is used by sender to appropriately set ^λcwnd' and ^λssthresh' after packet loss (indicated by three duplicate PACKs, or Timeout) . When three duplicate ACKs are detected:

• set ssthresh=FSE*RTTmin

_• if (cwnd > ssthresh) set cwnd=ssthresh where RTTmin is the minimum round trip delay experienced for the connection. When a timeout occurs:

_• set ssthresh=FSE*RTTmin and cwnd=l

Referring back to FIG. 1, the SC host 140 provides the peer A 110 with access to the network 130, for example by acting as a gateway, or as Home Agent of Mobile Internet Protocol (MIP) . For devices such as mobile telephone handsets, the link between the peer A 110, such as a mobile communications device, and the SC host 140, such as a wireless network base station, is provided by a wireless connection, such as a Global System for Mobile communication (GSM) , or 2G, connection, a General Packet Radio System (GPRS), or 2.5G, connection, or a Universal Mobile Telecommunications System (UMTS) , or 3G, connection .

Traditionally, such mobile communication devices have limited processing power and/or functionality, and as a consequence are sometimes not adapted to perform tasks such as TCP optimisation described above. Consequently, it is known for the SC host 140 to intercept transmissions from peer A 110 and perform the TCP optimisation on behalf of the peer.

With advances in technology, devices such as mobile telephone handsets are being provided with increased processing power, and increased functionality. Consequently, it is becoming more and more common for such devices to be adapted to perform such tasks as TCP optimisation . The inventors have recognised a problem with known systems, in that even when a device, for example peer A 110 in FIG. 1, is adapted to perform TCP optimisation, the SC host 140 will intercept transmissions from peer A 110, and also perform TCP optimisation thereon. Not only is it unnecessary for the SC host 140 to perform TCP optimisation in such as situation, since the peer A 110 is already providing TCP optimisation, it also adds a delay in the transmission of the data. Such a delay is clearly undesirable. Thus, there exists a need for improved handling of transmissions . BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views and which together with the detailed description below are incorporated in and form part of the specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present invention.

FIG. 1 illustrates an example of a known peer-to- peer connection via split connection host.

FIG. 2 illustrates a method of handling interconnection transmissions in accordance with an embodiment of the invention.

FIG. 3 illustrates a method of determining the TLA ability of a peer in accordance with an embodiment of the invention . FIG. 4 illustrates a method of handling interconnection transmissions destined for a local peer in accordance with an embodiment of the invention.

FIG. 5 illustrates an example of an interconnection host server adapted to perform the inventive concept of the invention.

DETAILED DESCRIPTION

Before describing in detail embodiments that are in accordance with the present invention, it should be observed that the embodiments reside primarily in combinations of method steps, functions and apparatus components related to a method and apparatus for handling interconnection transmissions. Accordingly, the apparatus components and method steps have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Thus, it will be appreciated that for simplicity and clarity of illustration, common and well-understood elements that are useful or necessary in a commercially feasible embodiment may not be depicted in order to facilitate a less obstructed view of these various embodiments.

It will be appreciated that embodiments of the invention described herein may be comprised of one or more generic or specialized processors (or 'processing devices' ) such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and apparatus for handling interconnection transmissions described herein. The non-processor circuits may include, but are not limited to, a radio receiver, a radio transmitter and user input devices. As such, these functions may be interpreted as steps of a method to perform the handling of interconnection transmissions described herein. Alternatively, some or all functions could be implemented by a state machine that has no stored program instructions, or in one or more application specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic. Of course, a combination of the two approaches could be used. Both the state machine and ASIC are considered herein as a processing devices' for purposes of the foregoing discussion and claim language . Moreover, an embodiment of the invention can be implemented as a computer-readable storage element having computer readable code stored thereon for programming a computer (e.g., comprising a processing device) to perform a method as described and claimed herein. Examples of such computer-readable storage elements include, but are not limited to, a hard disk, a CD-ROM, an optical storage device and a magnetic storage device. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

Generally speaking, pursuant to the various embodiments, the invention relates to a method of handling interconnection communication comprising the steps of: receiving a transmission from a peer; ascertaining whether the peer from which the transmission was received is adapted to perform transmission loss assessment; and if the peer is not adapted to perform transmission loss assessment, to implement transmission loss assessment on behalf of the peer.

In this way, when a transmission is received from a sender that is adapted to perform transmission loss assessment, the fact that the sender is adapted as such is recognised. Further, as a consequence, the unnecessary duplication of implementing transmission loss assessment can be avoided, thus avoiding unnecessary delay in the transmission. Those skilled in the art will realize that the above recognized advantages and other advantages described herein are merely exemplary and are not meant to be a complete rendering of all of the advantages of the various embodiments of the invention. Referring now to the drawings, and in particular FIG. 2, a method of handling interconnection transmissions, and in particular a method of handling interconnection transmissions from a local peer, is shown and indicated generally at 200. Those skilled in the art, however, will recognize and appreciate that the specifics of this illustrative example are not specifics of the invention itself and that the teachings set forth herein are applicable in a variety of alternative settings. For example, since the teachings described do not depend on a specific relationship with the sender of a transmission, they can be applied to any sender of a transmission, although a local peer is shown in this embodiment. As such, other alternative implementations are contemplated and are within the scope of the various teachings described. The method 200 of FIG. 2 begins at step 210, with the receipt of a transmission from, for the illustrated embodiment, a local peer.

For clarity, the local peer may be any device or apparatus that communicates via the apparatus performing the method 200 of FIG. 2. For the example of a split connection 100 illustrated in FIG. 1, in the scenario where the SC host 140 is adapted to perform the method 200 of FIG. 2, the local peer from which the transmission is received may be peer A 110.

As previously mentioned, the invention is not limited to a specific relationship with the sender of a transmission. However, for the exemplary embodiments described herein, a relationship such as that between the SC host 140 and the peer A 110 of FIG. 1 has been adopted to convey the inventive concept.

As previously mentioned, devices communicate across networks by way of protocols, these protocols acting as a set of rules governing how information, data, etc. is to be sent and/or received.

The Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite has become the de facto standard for computer communications in today's networked world. The exemplary embodiments described herein will be based on the handling of TCP/IP transmissions. However, it will be appreciated by a skilled artisan that the invention is not limited to the handling of TCP/IP transmissions, but may readily be applied to the handling of transmissions based on other protocols that provide for transmission loss assessment (TLA) .

IP is a standard protocol with STD number 5. The current IP specification can be found in RFCs 791, 950, 919 and 922, with updates in RFC 2474. IP is the protocol that hides the underlying physical network by creating a virtual network view. It is an unreliable, best-effort, and connectionless packet delivery protocol. Note that best-effort means that the packets sent by IP may be lost, arrive out of order, or even be duplicated. IP assumes higher layer protocols will address these anomalies .

TCP is a standard protocol with STD number 7. TCP is described by RFC 793 - Transmission Control Protocol. The primary purpose of TCP is to provide reliable logical circuit or connection service between pairs of processes. It does not assume reliability from the lower-level protocols (such as IP) , so TCP must guarantee this itself.

Some important features of TCP include:

• Stream Data Transfer: From the application's viewpoint, TCP transfers a contiguous stream of bytes through the network. The application does not have to bother with chopping the data into basic blocks or datagrams. TCP does this by grouping the bytes in TCP segments, which are passed to IP for transmission to the destination. Also, TCP itself decides how to segment the data, and it can forward the data at its own convenience.

• Reliability: TCP assigns a sequence number to each byte transmitted and expects a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is re-transmitted. Since the data is transmitted in blocks (TCP segments), only the sequence number of the first data byte in the segment is sent to the destination peer. The receiving TCP uses the sequence numbers to rearrange the segments when they arrive out of order, and to eliminate duplicate segments. • Flow Control: The receiving TCP, when sending an ACK back to the sender, also indicates to the sender the number of bytes it can receive beyond the last received TCP segment, without causing overrun and overflow in its internal buffers. This is sent in the ACK in the form of the highest sequence number it can receive without problems. This mechanism is also referred to as a window-mechanism.

Referring back to step 210 in FIG. 2, in the case of

TCP/IP transmissions, the receipt of a transmission refers to the receipt of a TCP/IP datagram or segment.

As will be appreciated by a skilled artisan, a received datagram would form a part of a sequence of such datagrams .

Having received a transmission from the local peer, the next step 220 is to determine whether the local peer is known. In an exemplary embodiment, a local peer is known if information relating to that local peer is available within a database or connection map, such information comprising at least transmission loss assessment ability.

If the local peer is not known in step 220, the next step 230 is to determine whether the local peer performs transmission loss assessment (TLA) . An example of determining whether the local peer performs TLA is illustrated in FIG. 3, and is described in more detail below. With regard to determining the TLA ability of the peer, in step 230, a single transmission may not be sufficient. Therefore, in an exemplary embodiment the TLA ability of a local peer is determined following the receipt of a plurality of transmissions from that peer.

For example, upon receipt of a single transmission from a local peer, a TLA determination function is called, to which the transmission, or information relating thereto is passed. Following receipt of a plurality of transmissions from the peer, the TLA ability thereof can be determined.

The transmission is then generally forwarded to the intended recipient (e.g. for a TCP/IP transmission the destination address), in step 240.

In an exemplary embodiment, which will be described in further detail with reference to FIG. 3, a transmission received from an unknown peer may be "dropped", i.e. not forwarded on to the intended recipient, as part of the process of determining the TLA ability of the peer. Where this is the case, step 240 is omitted.

Referring back to step 220, if the local peer is known, for example when information relating to that peer is available within a database or connection map, the method 200 moves to step 250. In step 250, it is verified whether the peer is adapted to use TLA, for example based on information available within the database or connection map. If the peer is not adapted to perform TLA, the method 200 moves to step 260, where the transmission is passed to a TCP stack of, for example, the SC host on which the method 200 is being implemented in order for TLA to be provided. The method then ends at step 270.

Referring back to step 250, if the peer is adapted to perform TLA, step 260 is omitted, and the transmission is forwarded "as is" to the intended recipient, in step 240. Finally, the method ends at step 270.

As will be appreciated by a skilled artisan, when a transmission is received from a sender that is adapted to perform transmission loss assessment, the fact that the sender is adapted as such is recognised. As a consequence, the unnecessary duplication of implementing transmission loss assessment can be avoided, thus avoiding unnecessary delay in the transmission. However, when a transmission is received from a sender that is not adapted to perform transmission loss assessment, the fact that the sender is adapted as such is recognised and transmission loss assessment is implemented on behalf of the sender.

Referring now to FIG. 3, there is illustrated a method 300 of determining the TLA ability of a peer in accordance with an exemplary embodiment of the invention. For the illustrated embodiment, the method 300 is expressed in a form of calling a TLA determination function. However, it will be appreciated that the method may be implemented in any alternative manner. For example, a discreet processing device may perform the method of TLA determination.

The method 300 in the illustrated embodiment begins at step 310, where the TLA determination function is called. Next, in step 320, it is determined whether the peer from which the transmission was received is a ^λpending peer' . As previously mentioned, a single transmission may not be sufficient for the purpose of determining the TLA ability of a peer. Thus, for the illustrated embodiment, the TLA ability of a local peer is determined following the receipt of a plurality of transmissions from that peer. A ^λpending peer' is a peer from which one or more transmissions have previously been received, but for which the TLA ability has yet to be determined. If the peer from which the transmission has been received is not a pending peer, the method 300 moves to step 330, where a profile is created for that peer.

For the illustrated exemplary embodiment, a receipt of a transmission refers to a receipt of a TCP/IP datagram or segment, and the TLA determination therefore refers to the TLA for TCP/IP transmissions.

As previously mentioned, a problem encountered when transmitting data is that of network congestion. To overcome this problem, various TCP congestion algorithms are known. TCP congestion algorithms prevent a sender from overrunning a capacity of the network (for example, slower WAN links) . Several congestion control enhancements have been suggested and added to TCP over the years. This is still an active and ongoing research area, but modern implementations of TCP contain four intertwined algorithms as basic Internet standards:

• Slow start

• Congestion avoidance

• Fast retransmit • Fast recovery

A fundamental problem with these known algorithms is that they assume that only one segment was lost. This can result in loss of ACK clocking and timeouts if more than one segment is lost.

Furthermore, several problems are encountered with multiple packet losses in a window of data (usually in the order of half a window) . For example, Fast Retransmit and Fast Recovery are invoked several times in succession leading to multiplicative decreases of ^λcwnd' and ^λssthresh' - impacting the throughput of the connection . Another problem encountered is known as ^λACK starvation' : this happens due to the ambiguity of duplicate ACKs and due to the dynamics of ^λcwnd' . Upon initially receiving duplicate ACKs, the sender sets ^λssthresh' to half ^λcwnd' , and reduces ^λcwnd' to equal ssthresh plus three times the segment size. With the continual receipt of duplicate ACKs, the sender increases ^λcwnd' so that it sends new packets until it fills the advertised window size (i.e. that set by the receiver). Upon receipt of a non duplicate ACK, the sender reduces the window size to equal ^λssthresh' (i.e. half its previous size prior to the receipt of the duplicate ACKs) .

However, due to multiple packet losses, this non duplicate ACK will be followed by three duplicate ACKs, signaling that another segment was lost. Thus, the sender again sets ^λssthresh' to half ^λcwnd' (potentially a quarter of the original size of ^λcwnd' ) , and reduces ^λcwnd' to equal ^λssthresh' plus three times the segment size. With the continual receipt of duplicate ACKs, the sender increases ^λcwnd' so that it sends new packets until it fills the advertised window size (for example, that set by the receiver) . Upon receipt of a non duplicate ACK, the sender reduces the window size to equal ^λssthresh' (for example, potentially a quarter of its previous size prior to the receipt of the initial duplicate ACKs) . If this happens several times in succession, the left edge of the sending window advances only after each successive non-duplicate ACK, and the amount of data in flight (sent but not yet ACK' d) eventually becomes more than the congestion window (successively halved by each invocation of Fast Re-transmit) . As there are no more ACKs to receive, the sender stalls and recovers from this dead-lock only through a timeout - which causes a slow start .

To overcome these problems, transmission loss assessment can be used, such as TCP optimisation algorithms. The purpose of TCP optimisation is to distinguish between random packet loss and network congestion. If a data packet is not received (or more appropriately an acknowledgement of a data packet is not received) due to random packet loss, then it is preferable to resend the lost packet without reducing the window size. In this way, the transmission rate is not unduly reduced. Conversely, when a data packet is lost due to network congestion (for example, the packet has been dropped by a router etc.), the window size should be reduced in order to free up network bandwidth.

When three duplicate ACKs are detected one approach is to : • set ssthresh=FSE*RTTmin

• if (cwnd > ssthresh) set cwnd=ssthresh where RTTmin is a minimum round trip delay experienced for the connection.

When a timeout occurs one approach is to: • set ssthresh=FSE*RTTmin and cwnd=l

Thus, for random packet loss (for example, when three duplicate ACKs are detected) the window size (cwnd) is not reduced, where as for network congestion (for example, when a timeout occurs), the window size is reduced.

Thus, for the illustrated exemplary embodiment, the TLA ability of a peer is determined by effectively simulating random packet loss, and observe a window size of received transmissions. Following a simulated random packet loss, if the window size is reduced, this implies that the peer is not adapted to use TLA. Conversely, if a window size is not reduced, this implies the peer is adapted to use TLA.

Random packet loss is simulated by dropping apparently random packets from a data stream. The effect of dropping a data packet is that the dropped data packet will not reach the intended recipient. Consequently, the intended recipient will not generate an ACK for that data packet. Instead, the intended recipient will generate a duplicate ACK upon receipt of the next data packet in the sequence. For each subsequent data packet received by the intended recipient, further duplicate ACKs will be generated.

In this manner, the sender of the data packets will recognise the fact that a data packet has been lost. As mentioned above, the response to such a loss will provide an indication as to the TLA ability of the sender.

Referring back to FIG. 3, in the next step 335, the window size of the received transmission is determined. As will be appreciated by a skilled artisan, the window size of a TCP/IP transmission is determined by the congestion window (cwnd) of the sender of the transmission. At this step the window size may be defined as part of TCP negotiation protocol during TCP connection establishment. The determined window size is then saved, in step 340.

Next, in step 345, it is determined whether the received transmission, i.e. the received data packet, should be dropped. This decision may be made based on an algorithm or the like, which keeps track of transmissions received from a peer, for example based on a profile for that peer. In this way, a number of packets dropped will not be too great as to significantly affect a transmission rate.

If it is decided to drop the received transmission, the method 300 moves to step 350, whereby the data packet is dropped, in step 350. This may be achieved by deleting the transmission prior to it being forwarded to the intended recipient, and bypassing step 240 of the method 200 of FIG. 2. The method 300 then moves to step 335, where the TLA determination function is closed.

Alternatively, if it is decided not to drop the received transmission, the method 300 moves straight to step 355, and the TLA determination function is closed. In this manner, the transmission will be forwarded to the intended recipient.

Referring back to step 320, if the peer from which the transmission has been received is a ^λpending peer' , the method 300 moves to step 360, where a profile for that peer is opened.

Next, in step 365, the window size of the sent transmission is determined. At this step the window size for sending may not be determined as part of TCP negotiations, since the TCP segment contains window size of receiving but not sending. The window size for receiving is not expected to be reduced in any case. It is envisaged that the determination of the window size for sending may be based on the counting number of the data bytes sent before receiving ACK with the proper sequence number. Having determined the window size, the next step 370 is to compare the window size to the window size as determined when the peer profile was created, namely that saved in step 340, to see whether the window size has been reduced (for example, due to the simulated random packet loss) .

If the window size has been reduced, in step 370 this would indicate that the peer is not adapted to use TLA. Therefore, the method 300 moves to step 380, where the TLA determination is saved. In this manner, when subsequent transmissions are received from that particular peer, for example in step 220 of the method 200 of FIG. 2, the peer will be known, and in step 250 of FIG. 2 the fact that it does not use TLA will be recognised. Alternatively, if the window size has not been reduced, in step 370, the method 300 moves to step 375, where a decision is made as to whether to close the peer profile or not. This decision is based on whether or not a TLA determination can be made.

This decision may be based on whether a sufficient number of transmissions have been received to determine the TLA ability of the peer. That is to say, following one or more packets being dropped to simulate random packet loss, if a predetermined number of subsequent transmissions have been received without the window size being reduced, such as ten, it can be assumed that the peer does use TLA.

Alternatively, if the received transmission contains the same data as that of a dropped transmission, for example, it is a retransmission of the dropped data packet, and the window size has not been reduced, this would indicate that the peer uses TLA.

If a TLA determination can be made, and therefore the profile is to be closed, the method 300 moves to step

380, where the determination is saved, and the profile is closed, in step 385.

Alternatively, if the profile is not to be closed, the method 300 moves to step 345. As explained above, in step 345 it is determined whether the received transmission, for example, the received data packet, should be dropped.

Referring now to FIG. 4, there is illustrated a method 400 of handling interconnection transmissions destined for a local peer, that is to say who's intended recipient is a local peer, in accordance with an exemplary embodiment of the invention. The method 400 begins at step 410, with the receipt of a transmission from, for the illustrated embodiment, a foreign peer, with the intended recipient being a local peer. In the case of TCP/IP transmissions, the receipt of a transmission refers to the receipt of a TCP/IP datagram or segment. As will be appreciated by a skilled artisan, a received datagram would form a part of a sequence of such datagrams . Having received a transmission from the foreign peer, the next step 420 is to determine whether the intended recipient, for example, the local peer is known. In an exemplary embodiment, a peer is known if information relating to that peer is available within a database or connection map, such information comprising at least transmission loss assessment ability.

If the local peer is not known, in step 420, the method 400 moves to step 430, where the transmission is forwarded to the intended recipient, for example, the local peer. The method then ends at step 460.

In an alternative embodiment, where the local peer is not known, in step 420 the transmission may be provided to, for example, a TLA determination function in order to aid in the determination of the TLA ability of the local peer.

Referring back to step 420, if the local peer is known, for example when information relating to that peer is available within a database or connection map, the method 400 moves to step 440. In step 440, it is verified whether the local peer is adapted to use TLA, for example based on information available within the database or connection map. If the peer is not adapted to use TLA, the method 400 moves to step 450, where the transmission is passed to the TCP stack of, for example, the SC host on which the method 400 is being implemented in order for TLA to be provided. The method then ends at step 460.

Referring back to step 440, if the peer is adapted to use TLA, step 450 is omitted, and the transmission is forwarded ^λas is' to the intended recipient, for example, the local peer, in step 450. Finally, the method ends at step 460.

As will be appreciated by a skilled artisan, when a transmission is received where the intended recipient is adapted to perform transmission loss assessment, the fact that the sender is adapted as such is recognised. As a consequence, the unnecessary duplication of implementing transmission loss assessment can be avoided, thus avoiding unnecessary delay in the transmission.

As previously mentioned, when a transmission is received from or to a local peer that is not adapted to perform transmission loss assessment, the transmission is passed to the TCP stack of, for example, the SC host in order for transmission loss assessment to be implemented.

It is known for SC hosts or the like to intercept transmissions to/from local peers, and to implement transmission loss assessment on behalf of the peer. Therefore a detailed explanation of this process is not required. However, for completeness, a brief explanation is provided below.

An example of transmission loss assessment implementation is TCP Westwood, which aims to enhance congestion control by way of Fair Share Estimates (FSE) . The sender calculates FSEs by sampling inter-arrival times of ACKs, and information provided within/by the ACKs about the number of bytes delivered. The FSE is then used by the sender to appropriately set cwnd and ssthresh after packet loss, as indicated by three duplicate ACKs or a timeout.

FSE is used by sender to appropriately set cwnd and ssthresh after packet loss (indicated by three DUPACKs, or Timeout) .

When three duplicate ACKs are detected: • set ssthresh=FSE*RTTmin

• if (cwnd > ssthresh) set cwnd=ssthresh where RTTmin is the minimum round trip delay experienced for the connection.

Thus, when the SC TCP stack receives transmissions from the local peer, it re-transmits them from itself in accordance with its own 'cwnd' and ^λssthresh' values. Similarly, when the SC TCP stack receives transmissions intended for the local peer, it uses these transmission to calculate FSEs, and then to appropriately set ^λcwnd'and ^λssthresh' as required and in accordance with transmission loss assessment. The SC TCP stack then forwards the transmissions on to the local peer and/or re-transmits transmissions from the local peer as required.

As will be appreciated by a skilled artisan, transmissions sent by the SC TCP stack will comprise a source address of the SC host. Consequently, if these transmissions were sent as generated by the SC TCP stack, the interception of transmissions by the SC host would not be transparent to the peers. Therefore, the SC host preferably intercepts the transmissions from the SC

TCP stack, prior to them being sent, and replaces the SC host address with that of the local peer address. In this way, the interception of the transmissions between the peers will be transparent.

Referring now to FIG. 5 there is illustrated an example of an interconnection host server adapted to perform the inventive concept of the invention. In order to show a practical example of these various teachings, however, the interconnection host server is illustrated in a form of a split connection (SC) host server. However, it is envisaged that the invention is not limited to an implementation by an SC host server, and may be implemented by any suitable interconnection host server, which is readily appreciated by one skilled in the art .

Turning now to FIG. 5, an SC host server 500 is shown and comprises a transmission intercept (TI) function 510, a connections map 530, a TLA determination function, and a TCP stack 540.

The TI function 510 is adapted to intercept transmissions from one or more local peers, to ascertain whether the local peer from which a transmission is received is adapted to perform transmission loss assessment, and to appropriately handle the received transmission depending on the determination.

For clarity, a local peer may be any device or apparatus that communicates via the SC host server 500.

In the case of TCP/IP transmissions, a receipt of a transmission refers to the receipt of a TCP/IP datagram or segment. As will be appreciated by a skilled artisan, a received datagram would form a part of a sequence of such datagrams.

The TI function 510 is further adapted to determine, upon receipt of a transmission from a local peer, whether the local peer from which the transmission is received is 'known' . For the illustrated embodiment, a peer is known if information relating to that peer is available within the connection map 520, such information comprising at least transmission loss assessment ability. Thus, upon receipt of a transmission from a local peer, the TI function 510 identifies the peer from which the transmission was received, for example by way of the "source" address provided within the transmission. The TI function 510 then compares this source address with those present in the connections map 520. If the source address matches one within the connections map 520, the peer is 'known' . Otherwise, the peer is not known.

If the local peer is not known, the TI function 510 determines whether the local peer performs transmission loss assessment (TLA) . For the illustrated embodiment, this is achieved by way of the TI function 510 calling the TLA determination function 530. In an exemplary embodiment, the TLA determination function 530 performs the method 300 illustrated in FIG. 3, and described in detail above.

As previously mentioned, a single transmission may not be sufficient. Therefore, in an exemplary embodiment, the TLA ability of a local peer is determined following the receipt of a plurality of transmissions from that peer.

For example, upon receipt of a single transmission from a local peer, the TLA determination function 530 is called, to which the transmission, or information relating thereto is passed. Following receipt of a plurality of transmissions from the peer, the TLA ability thereof can be determined. The transmission is then generally forwarded to the intended recipient (for example, for a TCP/IP transmission the destination address) .

In an exemplary embodiment, a transmission received from an unknown peer may be Mropped' , for example, not forwarded, as part of the process of determining the TLA ability of the peer. Where this is the case the transmission is not forwarded to the intended recipient.

The TI function 510 is further adapted to intercept transmissions for which an intended recipient is a local peer, to determine whether the local peer from which a transmission is received is adapted to perform transmission loss assessment, and to appropriately handle the received transmission depending on the determination.

Upon receipt of such a transmission for which an intended recipient is a local peer, the TI function 510 is further adapted to determine whether the local peer is known, in the same way as for transmissions received from a local peer.

If the local peer is not known, the transmission may be forwarded to the intended recipient, i.e. the local peer .

In an alternative embodiment, where the local peer is not known, the transmission may be provided to the TLA determination function 530 in order to aid in the determination of the TLA ability of the local peer.

If the local peer is known, TI function 510 verifies whether the local peer is adapted to use TLA, for example based on information available within the connection map 520. If the local peer is not adapted to use TLA, the transmission is passed to the TCP stack 540 in order for TLA to be provided. If the peer is adapted to use TLA, the transmission is forwarded ^λas is' to the intended recipient, i.e. the local peer.

In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. The benefits, advantages, solutions to problems, and any element (s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued. Moreover in this document, relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms "comprises," "comprising," "has", "having," "includes", "including," "contains", "containing" or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by "comprises ...a", "has ...a", "includes ...a", "contains ...a" does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms "a" and "an" are defined as one or more, unless explicitly stated otherwise herein. The terms "substantially", "essentially", "approximately", "about" or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art. The term "coupled" as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

Claims

CLAIMSWhat is claimed is:

1. A method of handling interconnection transmissions comprising the steps of: receiving a transmission from a peer; ascertaining whether the peer from which the transmission was received is adapted to perform transmission loss assessment; and if the peer is not adapted to perform transmission loss assessment, to implement transmission loss assessment on behalf of the peer.

2. The method of handling interconnection transmissions of Claim 1 further characterised in that the step of ascertaining whether the peer from which the transmission was received is adapted to perform transmission loss assessment comprises ascertaining whether the peer is known, and if known retrieving information from a database of connections map.

3. The method of handling interconnection transmissions of Claim 2 further characterised in that if the peer is not known, determining the transmission loss assessment ability of the peer by simulating random packet loss.

4. The method of handling interconnection transmissions of Claim 3 further characterised in that transmission loss assessment is determined by also observing the transmission window size.

5. The method of handling interconnection transmissions of Claim 4 further characterised in that the transmission loss assessment ability is determined based on whether the transmission window size is reduced following the simulated random packet loss; reduction in the transmission window size indicating that the peer is not adapted to perform transmission loss assessment.

6. The method of handling interconnection transmissions of any preceding Claim further characterised in that the transmission is a TCP/IP transmission.

7. The method of handling interconnection transmissions of Claim 6 further characterised in that providing transmission loss assessment comprises passing the transmission to a TCP stack.

8. The method of handling interconnection transmissions of any preceding Claim further characterised in that the if the peer is adapted to perform transmission loss assessment, the transmission is forwarded to its intended recipient .

9. The method of handling interconnection transmissions of any preceding Claim further characterised in that the peer is a local peer.

10. A method of handling interconnection transmissions comprising the steps of: receiving a transmission destined for a peer; ascertaining whether the peer for which the transmission is destined is adapted to perform transmission loss assessment; and if the peer is not adapted to perform transmission loss assessment, to implement transmission loss assessment on behalf of the peer.

11. The method of handling interconnection transmissions of Claim 10 further characterised in that the step of ascertaining whether the peer for which the transmission is destined is adapted to perform transmission loss assessment comprises ascertaining whether the peer is known, and if known retrieving information from a database of connections map.

12. The method of handling interconnection transmissions of Claim 11 further characterised in that if the peer is not known, determining the transmission loss assessment ability of the peer by observing the transmission window size.

13. The method of handling interconnection transmissions of Claim 12 further characterised in that the transmission loss assessment ability is determined based on whether the transmission window size is reduced following simulated random packet loss; reduction in the transmission window size indicating that the peer is not adapted to perform transmission loss assessment.

14. The method of handling interconnection transmissions of any of preceding Claims 10 to 13 further characterised in that the transmission is a TCP/IP transmission.

15. The method of handling interconnection transmissions of Claim 14 further characterised in that providing transmission loss assessment comprises passing the transmission to a TCP stack.

16. The method of handling interconnection transmissions of any of preceding claims 10 to 15 further characterised in that the if the peer is adapted to perform transmission loss assessment, the transmission is forwarded to its intended recipient.

17. The method of handling interconnection transmissions of any of preceding Claims 10 to 16 further characterised in that the peer is a local peer.

18. A transmission intercept function adapted to: intercept transmissions to and/or from one or more peers; ascertain whether a peer from which a transmission is received, or for which a transmission is destined, is adapted to perform transmission loss assessment; and if the peer is not adapted to perform transmission loss assessment, to implement transmission loss assessment on behalf of the peer.

19. The transmission intercept function of Claim 18 further characterised in that the transmission intercept function ascertains whether the peer is adapted to perform transmission loss assessment by way of ascertaining whether the peer is known, and if known retrieving information from a database of connections map .

20. The transmission intercept function of Claim 19 further characterised in that if the peer is not known, determining the transmission loss assessment ability of the peer by simulating random packet loss.

21. The transmission intercept function of Claim 20 further characterised in that transmission loss assessment is determined by also observing the transmission window size.

22. The transmission intercept function of Claim 21 further characterised in that the transmission loss assessment ability is determined based on whether the transmission window size is reduced following the simulated random packet loss; reduction in the transmission window size indicating that the peer is not adapted to perform transmission loss assessment.

23. The transmission intercept function of any one of Claims 18 to 22 further characterised in that the transmission is a TCP/IP transmission.

24. The transmission intercept function of Claim 23 further characterised in that the step of providing transmission loss assessment comprises passing the transmission to a TCP stack.

25. The transmission intercept function of any of Claims 18 to 24 further characterised in that the if the peer is adapted to perform transmission loss assessment, the transmission is forwarded to its intended recipient.

26. The transmission intercept function of any of preceding Claims 18 to 25 further characterised in that the peer is a local peer.

27. A host server adapted to perform a method of handling interconnection transmissions according to any of Claims 1 to 17.

28. The host server of Claim 27 further characterised in that the host server comprises a transmission intercept function according to any of Claims 18 to 26.

29. The host server of Claim 28 further characterised in that the host server further comprises one or more of the following : i) a connections map; ii) a transmission loss assessment function; iii) a TCP/IP stack

30. The host server of any of Claims 27 to 29 further characterised in that the host server is a split connection server.

31. A computer-readable storage element having computer readable code stored thereon for programming a computer to perform a method for handling interconnection transmissions according to any of Claims 1 to 17.

32. The computer-readable storage medium of Claim 31, wherein the computer readable storage medium comprises at least one of a hard disk, a CD-ROM, an optical storage device and a magnetic storage device.

33. The method of handling interconnection transmissions as hereinbefore described, with reference to and/or as shown in the accompanying drawings .

34. A host server as hereinbefore described, with reference to and/or as shown in the accompanying drawings .

35. A transmission intercept function as hereinbefore described, with reference to and/or as shown in the accompanying drawings .