US20100077251A1 - Method and system for reliably and efficiently transporting data over a network - Google Patents
Method and system for reliably and efficiently transporting data over a network Download PDFInfo
- Publication number
- US20100077251A1 US20100077251A1 US12/628,102 US62810209A US2010077251A1 US 20100077251 A1 US20100077251 A1 US 20100077251A1 US 62810209 A US62810209 A US 62810209A US 2010077251 A1 US2010077251 A1 US 2010077251A1
- Authority
- US
- United States
- Prior art keywords
- data
- proxy cache
- server
- receiving proxy
- packets
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/637—Control signals issued by the client directed to the server or network components
- H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1621—Group acknowledgement, i.e. the acknowledgement message defining a range of identifiers, e.g. of sequence numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/22—Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/64322—IP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L2001/0092—Error control systems characterised by the topology of the transmission link
- H04L2001/0097—Relays
Abstract
A data transport system for transporting data between a server (21) and a client receiver (27) over a network (23) includes a receiving proxy cache (25) coupled to a client receiver (27) via a reliable connection (29), such as a cable connection. The majority of data is transported from the server (21) to the receiving proxy cache (25) over an efficient data transmission channel (41). The receiving proxy cache (25) verifies the status of the data transmitted over the efficient channel (41). If there is an error in the data transmission, a portion of the data associated with the error is retransmitted from the server (21) to the receiving proxy cache (25) over a reliable data transmission channel (43). The complete data at the receiving proxy cache (25) is delivered to a client receiver (27) over a reliable connection (29).
Description
- The present application is a continuation of U.S. pending application Ser. No. 11/041,079 filed Jan. 21, 2005, which is a non-provisional of and claims the benefit of the filing date of U.S. Provisional Application Ser. No. 60/538,788, titled “Methods for Providing Reliable Transport Using UDP and TCP Protocols” and filed on Jan. 22, 2004, all of which we incorporate herein.
- The present invention relates, in general, to data transport and delivery over a network and, more specifically, to providing reliable delivery of media data over a potentially unreliable Internet Protocol network. Typically, the transport and delivery of media data over a network is an especially demanding application, as the data payloads are large, and the real-time constraints are stringent.
- Internet Protocol (IP) networks have become ubiquitous data infrastructures for delivering digital information world wide, particularly for data, voice and streaming video. As an increasing amount of data traffic delivered over IP networks contains multimedia content, the issue of providing reliable and high-throughput transport of such data has become more important.
- For example, in a system for delivering media content (particularly digital video content) that may or may not be compressed, there are servers for sending out the media content and receivers for receiving the media content. The server typically holds the content in disk drive based storage arrays. The receivers may also store the received content in local disk drive arrays, or may decode and display the content on local display devices. Such an environment has several aspects that differentiate it from other forms of data delivery. First, the data files are typically very large, comprising multiple gigabytes (GB) or more of data. Second, the data delivery must be at a high bit rate, usually at multiple megabits per second or higher. Furthermore, certain levels of timing control must be maintained during the delivery. These timing requirements impose restrictions on the amount of acceptable delay and delay jitter during the data transmission.
- Many network infrastructures, however, are designed and implemented with non-time-sensitive computer data in mind. Reliable delivery of data is guaranteed by end-to-end network protocols, e.g., Transmission Control Protocol (TCP) protocols. In TCP protocol, data is transferred and verified by both the sender and receiver to ensure correctness (i.e., to ensure that the binary data is not altered due to data transmission errors). Such protocols have evolved over the years to become capable of delivering data over different types of network transmission lines and over long distances.
- For digital media content, particularly for digital video data, merely delivering the data without bit errors is often insufficient. Digital video data usually has a timing requirement because encoded video images must be decoded at the receiver at fixed time intervals. As a result, the receiver's decoder buffer must have sufficient data for decoding. For real-time delivery of a compressed video bitstream over a network, the data blocks must arrive at the receiver at prescribed times to avoid receiver buffer overflow or underflow. In addition, when the digital media content is delivered over a network under the direction of the receiving client, end-to-end transport latency must be low. However, the TCP network transport protocol is not designed for such real-time delivery with low latency because they do not guarantee the end-to-end delay jitter and latency of the delivered data. As a result, even though data may arrive at the receiver correctly, it may arrive either too late or too early. In addition, the computational complexity of the TCP protocol is relatively large because both the sender and the receiver must each maintain state machines at their end of the connection. “State machines” are well known to those of ordinary skill—this refers to “finite state machines” which can be in a limited number of states, and which change from one state to another in response to an event, such as the arrival of a given packet from the other party over, for example, a TCP connection. These state machines are designed to help ensure that the transmitted data blocks are all accounted for, whether they are in a server buffer, in a receiver buffer or in transit from the server to the receiver. In addition, the state machines maintain the order of the data arriving at the receiver and deal with lost, duplicate, and out-of-order data blocks or packets. Often this additional computational overhead is taken up by co-processor engines designed to offload and handle only the TCP processing, which improves performance at the expense of increased overall system cost and complexity.
- When using the TCP protocol, the server holds the data in the server buffer until it receives confirmation from the receiver that up to a certain amount of data has been received, at which point the server buffer is cleared of the successfully transmitted data blocks. The server maintains a finite buffer size, often referred to as its transmission window. If the server transmit buffer is full and no portion of its data has been confirmed by the receiver as being correctly received, the server will stop transmission until either such confirmation arrives or a time-out occurs. At time-out, a portion of the data in the server buffer will be retransmitted and the whole process begins again. In addition, adaptive slow-start algorithms are used to ensure that transmitted data does not flood the network causing massive retransmissions and reducing the overall efficiency.
- With the TCP protocol, it is possible to send data packets via many different paths through an IP network and still ensure that the packets are delivered to the destination process in correct order without duplicates, errors or packet loss. The throughput of such transport protocols, however, depends on the quality of the transport network delivery, which is based on factors including bit error rate, packet loss rate, transmission delay and jitter, packet re-order rate, etc. For example, if a data block is lost during transit within the network, the server must wait till time-out and then retransmit the data block. Network delivery latency, packet loss, and packets out-of-order may significantly decrease the end-to-end transport throughput through retransmissions and time-outs.
- An alternate transport protocol, User Datagram Protocol (UDP), was developed to create alternatives to the constraints imposed by TCP. UDP can be used to increase end-to-end transport throughput. It tends to be less complex than TCP, but it does not offer the above-described features that can make TCP so useful in certain applications, such as guaranteeing against lost, duplicated, or out-of-order packets. Instead, the UDP protocol is a stateless implementation that does not require the server and receiver to each maintain a state machine to ensure correct transmission. Specifically, with the UDP implementation, an application process at the server segments the data into blocks, encapsulates them into UDP and then IP packets, and delivers them over the IP network with best efforts (i.e., without waiting for receiving acknowledgement). As a result, there is no retransmission of packets and no sliding windowing buffers. A server using UDP is thus capable of delivering data blocks very efficiently without the need to hold the data in its buffer and wait for confirmation, but lost and out-of-order packets are not reported to the server. Therefore, UDP transport does not ensure the quality of data delivery and is usually suitable only for use in reliable networks or for situations where unreliable data delivery is acceptable by the end applications.
- The foregoing illustrates that UDP and TCP based transmissions each have their own benefits and weaknesses. UDP transmission is efficient, and because it does not require a one-to-one connection between the sender and the receiver, it can also be used to provide multicasting of video or other rich content (e.g., delivering copies of the same video data to multiple locations). In addition, end-to-end transmission delay is bounded by the inherent delay of the network transport as no retransmission is provided and thus there is no extra buffer delay within the server. As previously discussed, however, UDP transmission cannot guarantee data transmission reliability. On the other hand, while TCP based transmissions are highly reliable, general control of delivery timing is not possible because it is a function of the quality of service (QoS) of the underlying network. An unreliable network will force retransmission of packets, resulting in excessive delays. Thus the average end-to-end delay and delay jitter can well exceed that of the actual network transport delay and delay jitter.
- In sum, for large scale distribution of digital video programs through digital cable, digital subscriber line (DSL), Ethernet or other broadband networks, it is extremely important that the digital video data can be delivered to large number of end client receivers with high efficiency, high bandwidth and reliability. This places significant demands on the network, content storage, distribution equipment, and processing requirement to achieve high input/output (I/O) throughput and more importantly, the QoS required for these applications. It would, therefore, be advantageous to have a method and a system capable of transporting such data over different types of networks with high efficiency, low latency and high reliability.
- The present invention comprises, in a number of embodiments, a method and system for reliably and efficiently transporting data over a network. The method and system of these embodiments has high data transport throughput with minimum transmission delay and buffer delay. The method and system of these embodiments is also able to guarantee data delivery to the receiving process in the right order. In accordance with one embodiment, the present invention provides a method and a system for establishing reliable data transport using a data caching system. A key benefit of the data transporting method in accordance with the present invention is that it is capable of transporting data at an efficiency comparable to that of User Datagram Protocol (UDP) transport while maintaining complete reliability like that of the Transmission Control Protocol (TCP) transport.
- While various embodiments are discussed in terms of digital video programs, it would also be advantageous to be able to distribute other data having similar performance requirements, such as visualization input data for large-scale distributed scientific visualization systems. Thus, the following description is intended to encompass transporting data not only for video programs, but for content data of all types. Other features and advantages of the present invention will become apparent to those of skill in the art through consideration of the ensuing description, the accompanying drawings, and the appended claims.
-
FIG. 1 illustrates a process for encapsulating data into a network protocol data packet in accordance with an embodiment of the present invention; -
FIG. 2 illustrates a system for transporting data over a network in accordance with an embodiment of the present invention; -
FIG. 3 illustrates a system for distributing data from a receiving proxy cache to a plurality of client receivers in accordance with an embodiment of the present invention; -
FIG. 4 illustrates a process for transporting data packets in accordance with an embodiment of the present invention; -
FIG. 5 illustrates a data retransmission process for data in error in accordance with an embodiment of the present invention; -
FIG. 6 illustrates a User Datagram Protocol data packet with a sequence number field attached thereto in accordance with an embodiment of the present invention; -
FIG. 7 illustrates a buffer structure in a receiving proxy cache in accordance with an embodiment of the present invention; -
FIG. 8 illustrates an assembly buffer in a receiving proxy cache in accordance with an embodiment of the present invention; -
FIG. 9 illustrates a cache buffer in a receiving proxy cache in accordance with an embodiment of the present invention; and -
FIG. 10 illustrates the degree of data retransmission urgency in a receiving proxy cache buffer in accordance with an embodiment of the present invention. - Various embodiments of the present invention are described hereinafter with reference to the drawings, in which the same or related reference numerals are used to represent related elements throughout the figures. It should be noted that the figures are only intended to facilitate the description of specific embodiments of the invention. They are not intended as an exhaustive description of the invention or as a limitation on the scope of the invention. In addition, an aspect described in conjunction with a particular embodiment of the present invention is not necessarily limited to that embodiment and can be practiced in conjunction with any other embodiment of the invention.
-
FIG. 1 illustrates how data is encapsulated into network protocol packets. By way of example,FIG. 1 shows aprocess 10 in which Motion Pictures Coding Experts Group (MPEG)transport packets 11 are encapsulated into Internet Protocol (IP)packets 16. First, one or moreMPEG transport packets 11 are encapsulated into a UDP orTCP packet payload 12. A UDP orTCP header 14 is added to UDP orTCP packet payload 12. The combination of UDP orTCP header 14 and UDP orTCP packet payload 12 is then encapsulated into one or moreIP data packets 16, which are each preceded by anIP header 18. It should be noted that what content is contained inMPEG transport packets 11 or whetherpayload 12 includes MPEG packets or some other data is immaterial toIP packet 16, and other types of data are contemplated as being within the scope of the present invention. -
FIG. 2 illustrates anexemplary system 20 for transporting data over a network or an internet in accordance with the present invention.System 20 includes aserver 21, atransport network 23, a receivingproxy cache 25, and aclient receiver 27.Server 21 functions as a sender for sending data to receivingproxy cache 25 acrossnetwork 23. Receivingproxy cache 25 functions as a receiver for receiving data transmitted fromserver 21 overnetwork 23. Generally,network 23 is assumed to be unreliable and susceptible to data packet loss, data packet reordering, and excessive data transmission delay with uncertain latencies. Adata stream connection 29 between receivingproxy cache 25 andclient receiver 27 is assumed to be reliable, or if not, a reliable transmission method based on TCP or methods described in this invention can also be utilized between receivingproxy cache 25 andclient receiver 27. Receivingproxy cache 25 relays or forwards the data received fromserver 21 overnetwork 23 toclient receiver 27 overconnection 29. In this respect, receivingproxy cache 25 functions as a data relay buffer or a memory device for temporarily storing the data forclient receiver 27. By way of example,connection 29 between receivingproxy cache 25 andclient receiver 27 may be a cable distribution network where the connection is mostly pre-provisioned point-to-point transport, or can be digital subscriber line (DSL) or Ethernet based networks. In accordance with various embodiments of the present invention,connection 29 can be implemented with coaxial cables, Digital Subscriber Line service (DSL),Layer 2 metropolitan Ethernet networks,Layer 3 IP networks, optical fiber networks, etc. -
Server 21 holds the digital content programs, such as video media content to be delivered to one ormore client receivers 27.Server 21 establishes connections with receivingproxy cache 25 throughnetwork 23. Receivingproxy cache 25 may be, for example, a media caching system that has a large local cache. A local cache is typically implemented by solid state dynamic RAM (DRAM) buffer memory, which have significantly higher input/output (I/O) throughput and much lower latency than disk drive based storage. In applications where the I/O throughput requirement is not high, disk drive based storage systems can also function as a cache. Because reliable data transport must be established betweenserver 21 andclient receivers 27, receivingproxy cache 25 is preferably capable of repairing the loss of data packets, or the out-of-order arrival of data packets, by requesting and accepting retransmitted data packets, and by reordering the data packets received fromserver 21 where necessary. Receivingproxy cache 25 is also preferably capable of discarding duplicate packets upon their arrival. -
FIG. 3 illustrates anexemplary system 30 for distributing data from receivingproxy cache 25 to a plurality ofclient receivers 27 in accordance with the present invention. As shown inFIG. 3 , data, e.g., compressed or uncompressed video data, is delivered from receivingproxy cache 25 via agigabit Ethernet interface 31 to an edge Quadrature Amplitude Modulation (QAM)gateway 33.Edge QAM gateway 33 packages the video data into groups, referred to as multiplexes. Logical information is embedded in the video data so that the video programs can be separated from the multiplexes later at the receiver side. The multiplexes are delivered in QAM channels overcoaxial cable networks 34 toclient receivers 27, which in FIG. are illustrated as comprising consumer digital set-top boxes 36. Again, while video data is frequently cited here, this invention is equally suited to transporting and distributing other kinds of program content data having similar performance requirements. - It should be understood that the data might be distributed from receiving
proxy cache 25 to theclient receivers 27 via other means. For example, in accordance with an alternative embodiment of the present invention, receivingproxy cache 25 may deliver the video program data over IP to a DSL Access Multiplexer (DSLAM), which then delivers the content to many individual DSL-attached client receivers. In accordance with another alternative embodiment, the content may then be directly delivered over aLayer 2 network (e.g., a metropolitan Ethernet network) or aLayer 3 network (e.g., an IP network). In accordance with yet another alternative embodiment, receivingproxy cache 25 delivers the video program data over optical fiber network toclient receivers 27. A specific implementation of this embodiment may include delivery of the digital program data over a fiber network to a gateway or interface on or near the premises whereclient receivers 27 are located. The gateway or interface converts the signal to an electronic signal for the final delivery to theclient receivers 27, which, by way of example, may be set-top boxes 36. -
FIG. 4 illustrates an exemplary embodiment of aprocess 40 for transporting data packets in accordance with a preferred embodiment of the present invention. To simplify the description of thedata transport process 40 and by way of example, the data packets are assumed to have a uniformly fixed size. However, it should be understood that the present invention is equally applicable to data packets having variable sizes. Two separatelogical channels server 21 and receivingproxy cache 25.Channel 41 is a one-way data transport channel with high efficiency but potentially low reliability.Channel 43 is a two-way data transport channel that is reliable but less efficient thanchannel 41. In accordance with the present embodiment, the majority of the data, represented byreference numeral 42 inFIG. 4 , is delivered over highlyefficient channel 41; and the portion of data in error, represented byreference numeral 44 inFIG. 4 , is retransmitted overreliable channel 43. - For each continuous video program transmission from
server 21 to receivingproxy cache 25,server 21 establishes two separatelogical data paths server 21 and receivingproxy cache 25. All actual deliveries of packets along a given logical path may not necessarily follow the same physical transmission link. In addition, multiple logical paths may share the same physical transmission link. Data paths established using UDP and TCP connections are two examples of logical data channels. UDP data paths are connectionless and highly efficient. TCP data paths are connection oriented, more reliable, but less efficient than UDP data paths. -
Server 21 transmits data packets in two or more channels, e.g.,channels FIG. 4 . In accordance with one embodiment of the present invention,server 21 delivers the data packets to receivingproxy cache 25 according to UDP viaprimary delivery channel 41. For example, in the case of an MPEG-2 transport stream,server 21 fragments and encapsulates the data packets as the payload of a sequence of UDP packets. Additional packet header data may be inserted to carry timestamp information, such as those defined by the Real Time Protocol (RTP) standards. Insecondary delivery channel 43, data packets are transmitted fromserver 21 to receivingproxy cache 25 using a highly reliable delivery protocol, e.g., TCP. In accordance with the present invention,secondary channel 43 may be used only to deliver those packets that receivingproxy cache 25 does not receive correctly overprimary delivery channel 41 due to packet error, packet loss or a packet arriving out-of-order. - It should be noted that the above-described
process 40 for transporting data is not limited to employing UDP and TCP protocols. Other protocols with similar characteristics (i.e., those with higher efficiency but lower reliability and those with higher reliability but lower efficiency) can also be used in accordance with the present invention. - In order to determine which
channel server 21 will use to deliver a data packet,server 21 preferably receives notification from receivingproxy cache 25, which functions as a receiver for the data packets transported fromserver 21. In a normal transmission situation,server 21 delivers all data packets throughchannel 41 which results in a high transport efficiency and throughput. When transmission errors occur, some packets may be corrupted, lost or reordered inchannel 41. Receivingproxy cache 25 then detects these errors and notifiesserver 21 of such problems. Such errors may be due to lost IP packets, out-of-order packets, duplicate packets, and bit errors within the packet payload. The UDP protocol optionally carries an error detection mechanism that allows a receiver (e.g., receivingproxy cache 25 inFIG. 4 ) to determine whether there are data errors within the payload of the UDP packet. However, the UDP protocol does not provide ways to tell the receiver whether an IP packet carrying UDP payload is lost. Detecting lost data packet is achieved by methods outside the scope of the UDP protocol implementation. In addition, receivingproxy cache 25 is preferably able to identify the precise location of the portion of data in error. - Upon detecting reception errors, receiving
proxy cache 25 requests retransmission of the data packet in error viareliable channel 43. The retransmitted data packet may then be assembled back into the received copy of the original transmitted stream, which is being held in a buffer at receivingproxy cache 25. The data in the buffer at receivingproxy cache 25 is not delivered to the client receivers (e.g.,client receiver 27 shown inFIG. 2 and set-top boxes 36 shown inFIG. 3 ) until the data integrity is established where needed via the retransmission and then verified by receivingproxy cache 25. - Because multiple errors may be detected in the received packet content, multiple retransmission requests may be initiated by receiving
proxy cache 25. The retransmission request preferably contains the location of the data portion in error. The location may be identified, for example, by an internally defined locator scheme agreed upon by both the sender and the receiver (e.g.,server 21 and receivingproxy cache 25, respectively). -
Server 21 retransmits data packets viareliable channel 43 in response to requests received from receivingproxy cache 25. In accordance with one exemplary embodiment of the present invention,server 21 does not maintain a transmission buffer for data delivered over theunreliable channel 41. When a retransmission request occurs,server 21 goes back to the original data content and identifies the data section to be retransmitted, and copies the data from stored files into a retransmission buffer (not shown inFIG. 4 ) for transmitting to receivingproxy cache 25 viareliable channel 43. Generally, the lost data represents a relatively small portion of the content delivered, and the retransmission buffer only needs to hold the portion of data to be retransmitted and not yet acknowledged as correctly received. Such retransmission activities usually occur only sporadically and only for the portion of data where loss is detected by receivingproxy cache 25. For example, if the data transmission error rate is about 5%, roughly 5% of the data will be retransmitted overreliable channel 43. - Transmission data loss may, however, be affected by the bit rate at which
server 21 delivers data to receivingproxy cache 25. Specifically, the network has a finite bandwidth capacity, which ideallyserver 21 should not exceed. By way of example, if the maximum available bandwidth ofchannel 41 is 100 megabits per second (Mbps), andserver 21 transmits the data at a bit rate of 200 Mbps, 50% of the data will be lost. However, in general, the available bandwidth within a network is not known toserver 21.Server 21 must estimate the available bandwidth based on information such as data packet loss rate, end-to-end delay, and other information returned from within the intermediate network nodes or from the receivingproxy cache 25. Preferably, the transmission rate ofserver 21 overefficient channel 41 is dynamically or adaptively controlled by time series values of such measured parameters as end-to-end delays and packet loss rate. - In the case when there are substantial amount of packet loss due to mismatch between the transmission rate and the available network bandwidth, the lost packets must then be delivered over the
reliable channel 43. As a result, unacceptably long end-to-end delays may occur as the TCP channel cannot keep up with the demand for retransmission. In addition, the increasing use of the TCP channel defeats the original objective of improving the transfer efficiency by using the UDP channel. In order to address this, the sender may need to throttle back the UDP delivery rate in correspondence to the number of retransmission requests pending on the TCP channel. - One approach is for the sender to maintain a count of the amount of data awaiting retransmission. The UDP delivery rate is reduced as the amount of data awaiting retransmission over TCP is increased. This feedback mechanism can be based on simple threshold, or based on continuous values. Let R, for example, be the delivery bit rate via the UDP channel. Let T be the amount of data to be retransmitted over a time-window of length S. For a threshold based mechanism, the value of R is updated periodically, such as follows:
- At start: R is set at maximum possible transmission rate
- While T=0: R=R+d, where d is a fixed increment
- The main purpose of the rate-reduction algorithm is to ensure that the UDP channel does not flood the available bandwidth and cause excessive data loss within the network itself. The main purpose of the rate-increase algorithm is to ensure that the available bandwidth is fully utilized. Larger values of d can quickly bring up the transmission efficiency, but may also cause some oscillation around the optimal operation point. The optimal operation point is when T stays close to zero. Given that the round-trip delay of the re-transmission request depends on the network conditions, the value of R will be adjusted up and down around the optimal point, but never exactly at the point. The values chosen for S and d depend on the size of the receiver buffer in the receiving proxy cache. If the receiving proxy cache has a very large buffer, S can be set to a larger value and d can be set to a larger value as well. From the above description, we can see that larger S and d implies that the response to increasing amount of pending retransmission is slower, which is acceptable because the receiving proxy cache has sufficient amount of cache buffer available. The value of S should be such that it is at least a multiple of round-trip-delay (RTT) of the network so that the amount of retransmission pending is a more accurate estimate of the amount of packet loss during transit, instead of a measure dominated by packets still in transit.
- A number of means may be used to obtain figures of merit for the underlying transport network between the transmitting server and the receiving proxy cache. The invention described here may be configured to use these figures of merit alone, or in any appropriate combination, as will be appreciated by one of ordinary skill in the art. One important measure is end-to-end delay between the transmitting server and the receiving proxy cache. Another is transmission delay jitter.
- There are a number of ways to measure end-to-end delay. One approach is to measure round-trip times between the transmitting server and the receiving proxy cache, and then divide by two to arrive at an estimated end-to-end delay. Another approach is to use highly accurate clocks, synchronized to GPS or perhaps via NTP (Network Time Protocol), in conjunction with transmit timestamps, to accurately measure the actual one-way delays. End-to-end delay is a good measure of the network congestion. In IP network terms, this is equivalent to half of the round-trip-time (RTT), which is the time it takes a packet to transit the IP network from source to destination and back. In this case, from the transmitting server to the receiving proxy cache. There are well known methods to estimate the RTT using the ‘ping’ and ‘traceroute’ commands thus we shall not go into further detail on this topic. It is important to point out that (RTT/2) is a reasonable estimate of the end-to-end delay for packets sent via a UDP channel. But for TCP, the end-to-end delay is generally much longer than RTT. This is because TCP performs retransmission of packets and also has time-out mechanisms, which can end up with an effective end-to-end delay much larger than the RTT.
- These figures of merit, as well as other key information, may readily be exchanged between the transmitting server and the receiving proxy cache, as will be appreciated by one of ordinary skill. For example, any important figures of merit to be sent in the “forward” direction by the transmitting server to the receiving proxy cache may be included where needed interspersed between payload data, or as additional header information. Similarly, any such real-time figures of merit that need to be sent from the receiving proxy cache to the transmitting server may be sent, for example, using UDP or a similar protocol. The system can be designed to minimize the effects of packet and information loss here by occasionally transmitting current updates in each direction as appropriate; if a given update is dropped or lost, the next update will most likely suffice. One possible approach is to combine ongoing “pilot” round-trip pings with metadata sequence numbers so that each party can at least tell when such an update has been lost, and can apply ordering appropriately.
- An alternative way to measure end-to-end transmission delay and jitter is to use a timestamp field 64 (
FIG. 6 ) that may be inserted into the payload of data packet 12 (FIG. 1 ). The timestamp indicates the time at which the associated data packet is transmitted fromserver 21. At receivingproxy cache 25, the timestamps embedded in two successive arriving packets are extracted. The difference between the two timestamps indicates the transmitting time difference, which may be represented by an algebraic symbol ΔTT, between the two data packets. Receivingproxy cache 25 measures the arriving time difference, represented by an algebraic symbol ΔTA, between the two corresponding data packets. Assuming that the clock inaccuracies of the clock atserver 21 is negligible, the end-to-end transmission delay jitter is represented by ΔTT minus ΔTA (i.e., the difference between the transmitting time difference and the arriving time difference of the two corresponding data packets). In a preferred embodiment, the time stamp field may be 32 bits in size with each increment representing, for example, 1 microsecond (μs). Accordingly, the wrap-around time of the time stamp field is about 1.19 hours. In this embodiment, no confusion will arise unless the interval between two successive packets delivered fromserver 21 exceeds 1.19 hours, which is practically impossible. - Measuring packet loss may be achieved through a sequence number field 66 (
FIG. 6 ) inserted into the payload of UDP packet 12 (FIG. 1 ). Receivingcache 25 can determine which packet is missing by inspecting the sequence number. - In accordance with one embodiment of the present invention,
server 21 delivers data packets to receivingproxy cache 25 overchannel 41 at a high initial bit rate, which may exceed the available bandwidth ofchannel 41 and therefore result in excessive data packet loss at receivingproxy cache 25. This initial high bit rate burst of data transfer preferably lasts a brief duration in order for receivingproxy cache 25 to be pre-filled with video data so that sufficient content is available in the buffer of receivingproxy cache 25 on behalf of the requesting client receiver, e.g.,client receiver 27. The data packet loss rate information at receivingproxy cache 25 is transmitted back toserver 21. - The retransmission request will be sent via the
TCP channel 43 as it is reliable. The retransmission requests may be in the form essentially of a list of packets for which retransmission is needed, in priority order. The retransmission request may not have to be a list of individual packets, however. As data loss within the network can be highly bursty, tens or hundreds of packets in a row may be lost. Therefore, a more efficient way may be to send back the sequence number of the first retransmitted packet along with the length of this packet ‘run.’ Thus, the server could efficiently determine which packets needed to be present. The server could even choose to ignore a high-priority retransmission request if it had already recently retransmitted a given packet. It is in many cases preferable for the server to execute all retransmission requests regardless of whether the request has been fulfilled before or not. The receiving proxy cache may, therefore, be relied upon to determine whether two retransmitted packets are the same and whether it thus needs to discard one of them. When there is sufficient buffering at the receiving proxy cache, this shifts the burden of the computation from the server to the receiving proxy cache.Server 21 may also determine whether or not to retransmit the lost packets. Alternatively,server 21 may decide not to retransmit the data and let the receivingproxy cache 25 provide its own ways to handle the lost data packets as the data is delivered to the requesting clients. - In accordance with one embodiment of the present invention,
proxy 25, upon detecting data loss, injects a separate video segment containing a status message saying something like “experiencing network delays”. The message may last a few seconds allowing receivingproxy cache 25 to read past the buffer portion of the lost data. In accordance with another embodiment, this status message injection is performed by theclient receiver 27 instead of the receiving proxy cache to the same effect. In accordance with another embodiment, receivingproxy cache 25 can repeat the last good Intra frame (I-frame) in the original MPEG video program data, resulting in a frozen display of the video sequence. For other forms of data, analogous methods may be used. - In a typical environment,
server 21 may deliver multiple video programs to receivingproxy cache 25. According to one embodiment,server 21 establishes a data transmission channel, e.g.,channel 41 shown inFIG. 4 , for each video program. In other words, an individual transmission channel is associated with each video program. This means that multiple data transmission channels, which are also referred to as transmission sessions, are required for transmitting multiple programs fromserver 21 to receivingproxy cache 25. Such sessions, e.g., UDP transmission sessions, can be dynamically allocated. In an alternative embodiment of the present invention, multiple video programs can share the same transmission channel or session. Different video programs can be logically separated within the same transmission session by using additional program identification fields. In one embodiment, the ability to uniquely identify different video programs is achieved by adding additional fields within the UDP payload 12 (FIG. 1 ). -
FIG. 5 illustrates adata retransmission process 50 in accordance with a preferred embodiment of the present invention. Retransmission overreliable channel 43 may result in multiple retransmission attempts of the actual data packets. Retransmission activity is performed within a reliable channel protocol, e.g., TCP, in a network protocol stack and driver level, and is transparent to server retransmission activity itself. In other words,server 21 considers that only oneretransmission 52 is needed for a lost data packet, even thoughmultiple retransmissions 54 may sometimes in fact be needed for the lost data packet within the TCP layer itself. - As mentioned above,
server 21 often delivers multiple video programs to receivingproxy cache 25. Data loss can occur in multiple video programs, resulting in multiple retransmission requests from receivingproxy cache 25. The retransmission of data is performed over a reliable channel, e.g.,TCP channel 43. In one embodiment,server 21 establishes a retransmission channel or session, e.g.,TCP channel 43, for each video program. In other words, an individual retransmission channel is associated with each video program. Therefore, multiple TCP sessions are required. Such multiple sessions may be dynamically allocated because video program requests are generally dynamic. Establishing and tearing down the TCP sessions can impose substantial amounts of time and processing cost and large numbers of retransmission sessions may also be limited by the number of available TCP ports. In an alternative embodiment and in order to improve the efficiency of the retransmission channel, multiple video programs may share the same retransmission channel. In this embodiment, the retransmission session may remain open for all retransmission requests. Different video programs may also be logically separated from each other within the same TCP session by using additional program identification fields. For example, the ability to uniquely identify different video programs can be achieved by adding additional fields within the TCP payload 12 (FIG. 1 ). - Generally, the receiving buffer (not shown in
FIG. 4 ) at receivingproxy cache 25 is large enough to contain data transmitted over a duration much longer than the round trip delay (often up to hundreds of times larger than round trip delays). There is generally a lack of urgency in detecting data in error and requesting retransmission unless the data in error is close to the read point for transmission from receivingproxy cache 25 to a client receiver, e.g.,client receiver 27 shown inFIG. 2 . - In accordance with another embodiment of the present invention, UDP header field 14 (
FIG. 1 ) may include a checksum field for detecting a data transmission error. Upon detecting a data transmission error, receivingproxy cache 25 treats the associated UDP packet as being lost and discards the packet from the buffer in receivingproxy cache 25. Therefore, erroneous data packets are treated the same as lost data packets. - In accordance with yet another embodiment of the present invention, erroneous data packets may be treated as immediate notice that retransmission will be required. Lost data packets and very late data packets are indistinguishable—when an expected packet has not arrived after a given time threshold, it is assumed to have been lost, and only then will retransmission be requested if appropriate. Whether the retransmission request is sent immediately depends on the urgency of the need for the retransmission. The receiving proxy cache sends an urgent retransmission request only when it detects that it will need the data relatively soon.
- In accordance with one embodiment of the present invention, a sequence number field is introduced into the transmitted data packets so that receiving
proxy cache 25 can determine which packet is missing by inspecting the sequence number. The sequence number fields may also be attached to the data packets. In a specific embodiment illustrated inFIG. 6 , asequence number field 66 is attached todata packet 60 as an extension ofUDP payload 62. In this particular embodiment,sequence number field 66 has 32 bits. However, a sequence number field may be of different sizes in accordance with a preferred embodiment of the present invention. - In accordance with another embodiment of the present invention, the data packet retransmission will be performed at the same level where
sequence number field 66 is inserted. In the specific embodiment illustrated inFIG. 6 ,sequence number field 66 is attached todata packet 60 as an extension ofUDP payload 62, and the retransmission is performed at the UDP level. Alternatively, the sequence number field is inserted at the transport packet level, e.g., at the level of MPEG transport packets. For example, a 32 bit sequence number field may be inserted once every 100 transport packets grouped together as a transport packet group. This sequence number then also appears as part of the transport stream payload. In this embodiment, the retransmission is performed at transport packet level. A transport packet group containing 100 transport packets is retransmitted as a whole even if only one transport packet in the transport packet group is lost. Of course, a transport packet group may have other fixed numbers of packets, say, 200, 1000, etc. It is worthwhile to point out that because each retransmission channel may use a different protocol, in the case of the need to retransmit payload originally sent on the UDP channel, the UDP packet itself is not sent in the retransmission channel. Rather, it is the UDP payload that gets retransmitted as the payload of the reliable TCP channel. The same can be said for the case of the transport packet group retransmission. - In the embodiment with sequence number field inserted in the UDP payload, the sequence number increases by one for each UDP packet delivered out of
server 21 for a given video program stream. The sequence number will generally wrap around to its original value at some point. If this wraparound period is short, it is possible that all data packets are lost during the entire wraparound period, which can mislead receivingproxy cache 25 to consider that fewer data packets are lost. In order to allow sufficient transmission before the sequence number field value wraps around, the sequence number field is preferably relatively large, e.g., 32 bits in size as shown inFIG. 6 . By way of example, if each UDP packet payload contains seven MPEG-2 transport packets as payload and each transport packet has a fixed length of 188 bytes, the sequence number field will wrap back to its original value after 4,294,967,296 UDP packets are sent. At 7.times.188 bytes per UDP packet payload, this is equivalent to about 5.6 terabytes (TBs) of data transmitted before the sequence number is wrapped back to the beginning. This means that the sequence number can identify up to 5.6 TBs of consecutive data loss. This is sufficient to handle almost all realistic cases of packet losses. Fewer bits may be used for the sequence number fields, resulting in more frequent wraparound of the field values. As long as the wraparound period is sufficiently long, the sequence number field can be used to correctly determine whether a packet is lost. - Because the transmission from
server 21 to receivingproxy cache 25 has end-to-end latencies and the delivered data packets may be out of order, receivingproxy cache 25 is preferably able to detect these out-of-order packets and hold off forwarding the packets toclient receiver 27 until all of the delivered packets are in the right order. A buffer in receivingproxy cache 25 may be used to temporarily store the delivered data packets. The tolerance level of the latencies determines the amount of buffering required. Considering that the packets can at most be out of order by the maximum number of packets in transit, the maximum out of order is therefore determined by the end to end delivery latency, which is closely tied to RTT. It is generally assumed, in the context of this invention, that the amount of buffering within the receiving proxy cache buffer is substantially larger than the number of packets in transit due to end-to-end latency. It should be understood, however, that this may not always be the case. - In accordance with an embodiment of the present invention shown in
FIG. 7 , receivingproxy cache 25 includes at least two buffers, i.e., anassembly buffer 72 and acache buffer 74, preferably close to each other.Assembly buffer 72 delivers its content tocache buffer 74.Buffers proxy cache 25 includes multiple pairs of assembly and cache buffers. In many instances, receivingproxy cache 25 with multiple pairs of assembly and cache buffers may be preferred in relaying multiple video programs fromserver 21 to client receivers, with one pair of assembly and cache buffers for each video program. - The received data packets are held in
assembly buffer 72 and will not be released tocache buffer 74 until all data packets are received and are in the right order. Therefore,assembly buffer 72 preferably has sufficient capacity to accommodate the maximum latency including detection of error packets and subsequent retransmissions of incorrectly received packets. -
FIG. 8 illustratesassembly buffer 72 withdata packets 82 stored therein. By way of example,FIG. 8 shows defectivedata packet locations server 21 to receivingproxy cache 25 over reliabledata transmission channel 43. Retransmission ofdefective data packets assembly buffer 72 is large enough to hold alldata packets 82 until all retransmitted data packets are correctly received. In other words, the size ofassembly buffer 72 is preferably sufficient for the longest possible end-to-end error detection and retransmission latency. -
Cache buffer 74 receives the data packets fromassembly buffer 72 and holds the content that is frequently accessed by the client receivers, e.g.,client receiver 27 shown inFIG. 2 . The size ofcache buffer 74 determines the efficiencies of the cache algorithms. Thelarger cache buffer 74, the more likely that requested media content is withincache buffer 74, and receivingproxy cache 25 can then deliver the content out ofcache buffer 74 without interacting withserver 21. The combined use of the reassembly buffer and cache buffer enables the receiving proxy cache to mask out the effect of retransmission to the clients. Specifically, if the clients request data from receiving proxy cache that has been received ahead of the delivery time, the clients experience no data deliver delay, all retransmission delays are absorbed by the assembly buffer. In other words, if the client is requesting a video bitstream from the receiving proxy cache, the receiving proxy cache can deliver the data with low or no latency. - Buffers are not necessarily first-in-first-out. For example, retransmission activity can disrupt the receiving order of the data packets within
assembly buffer 72. The correct ordering of the data packets withinassembly buffer 72 may be maintained by sequence numbering usingsequence number field 66 described above with reference toFIG. 6 . In one embodiment, the readout order of the data packets fromcache buffer 74 follows the original order at which the data packets are transmitted fromserver 21. In addition, multiple concurrent read-out requests of the same buffer can be performed, which implies that the buffer output is not in strict order. - In accordance with one embodiment of the present invention,
assembly buffer 72 andcache buffer 74 do not have to be separately constructed. In accordance with an alternative embodiment of the present invention,assembly buffer 72 andcache buffer 74 share the same logical buffer with a virtual boundary between them. In this embodiment, the retransmission activity is performed in the assembly portion of the buffer and the delivery-to-client activity is performed in the cache portion of the buffer. Once the head of line portion of the data content within the assembly portion is complete, it can be considered part of the cache portion. In other words, there is really no actual transfer or copy of data from the assembly portion to the cache portion. The boundary between the two buffer portions simply gets set to a new buffer location. As the cache portion gets freed up because older content data has been delivered toclient receiver 27, it may be re-allocated back to the assembly portion when needed via a memory manager. - Data in error is preferably retransmitted by
server 21 and successfully received at receivingproxy cache 25 before the data is delivered out of receivingproxy cache 25. Data errors may occur in different buffer locations of receivingproxy cache 25 as illustrated inFIG. 9 . In one situation, data inerror 93 may occur in locations that will not be read by aread pointer 95 in receivingproxy cache 25 for a significant time period because a substantial amount ofcorrect data 92 exists ahead of data inerror 93. In another situation, data inerror 91 may occur just before its anticipated access byread pointer 95. These two situations call for two different approaches to the retransmission. In the first case, since the urgency for retransmission is low, receivingproxy cache 25 may decide to postpone the retransmission request if there is a more urgent retransmission request. In the second case, the retransmission is preferably done as soon as possible, i.e., the urgency is high. Otherwise, readpointer 95 will reach data inerror portion 91 quickly and read the incorrect data. Therefore, retransmission of data in error is preferably prioritized according to the urgency of the data in error portion. - It should be noted that this data urgency may change according to the location of read
pointer 95 in receivingproxy cache 25. Because a buffer may have multiple read pointers for providing output to multiple client requests, the read pointers are dynamically adjusted according to the arrival and departure of client requests. Examples of client requests include play, fast-forward, rewind, pause, stop, etc. At any time, the urgency for retransmission for a data in error portion depends on its distance from its nearest read pointer, e.g., readpointer 95 inFIG. 9 , just ahead of data inerror portion 91, would have a relatively high urgency. The distance can be measured in number of bits, the amount of time, or the like. In an alternative embodiment, a movable virtual boundary in a logical buffer in receivingproxy cache 25separates assembly buffer 72 fromcache buffer 74. In this embodiment, the time it takes readpointer 95 to read from the current position to the end ofcache buffer 74 defines the urgency. It should be noted that the end ofcache buffer 74 is also the beginning ofassembly buffer 72, where the data in error exists. - An urgent retransmission request implies that the data should be retransmitted soon. Otherwise, receiving
proxy cache 25 risks not being able to deliver the data to the client receiver. Because the underlying IP network generally does not guarantee the end-to-end delivery latency required for on-demand data transmission environment, the urgency of the retransmission is reflected in the retransmission wait time of receivingproxy cache 25, i.e., the duration between the time when the retransmission request is generated and held in the retransmission request queue to the time when the retransmitted data is actually delivered to receivingproxy cache 25. Therefore, all else being equal, all retransmission requests are preferably sent out at the earliest possible time. Once the proxy caching process starts to run, some retransmission requests can be more urgent than others. In these cases, the urgency is usually not completely under the management control of receivingproxy cache 25. For example, as discussed, the urgency can also depend upon the changing demands at each client receiver. - In accordance with one embodiment of the present invention, the urgency when receiving
proxy cache buffer 74 is initially filled by the incoming data can be controlled. In this case, it is preferred to fill or constructcache buffer 74 as quickly as possible to establish an initial buffer fill so that readpointer 95 will have a substantial amount of available data ahead of potential data in error. Filling or constructingcache buffer 74 quickly reduces the risks of the portion of the missing data due to error being too close to readpointer 95. In this case, it may imply that other buffers may need to postpone receiving data until the buffer with urgent retransmission requests is filled to certain level first. - Accordingly, the transmission of data into receiving
proxy cache buffer 74 may have a degree of urgency associated with it. This degree of urgency is meaningful when there are multiple receiving proxy cache buffers, where each may be allocated for a different video program. The transmission urgency is a measure applied to specific video programs onserver 21. In a system whereserver 21 feeds data, e.g., video programs, to multiple receivers, e.g., receiving proxy caches,server 21 must determine which receiver buffer should receive data at the highest priority and the appropriate bit rate, as illustrated inFIG. 10 . Immediately filling a buffer in receivingproxy cache 25 with a large amount of data can reduce the urgency of retransmission requests since retransmission requests will thus likely be for data portions substantially further from the readpointer 95 shown inFIG. 9 . However, it is important to point out that theserver 21 must rely on the receiving proxy cache to provide the urgency information as the buffers are in the receiving proxy cache, not in the server. This information preferably is sent from the receiving proxy cache back to the sender via reliable return channel. Alternatively, it may be sent back occasionally and redundantly via an unreliable return channel. Therefore, the server decides which video program data to send first based on the priority set by the urgency measures provided by the receiving proxy cache. - By now it should be appreciated that a method and a system for transporting data between a server and a receiving proxy cache over a network has been provided. In accordance with one embodiment of the present invention, the data is transported from a server to a receiving proxy cache over two logical channels. The data is first sent from the server to the receiving proxy cache over an efficient data transmission channel. The receiving proxy cache verifies the status of the data transmitted over the efficient channel. If there is an error in the data transmission, a portion of the data associated with the error is retransmitted from the server over a reliable data transmission channel. The data transport system of the present invention is both efficient and reliable. It has high data transport throughput with minimum transmission delay and minimum buffer delay. It is also able to guarantee data delivery to the receiving process in the right order.
- While various embodiments of the present invention have been described with reference to the drawings, these are not intended to limit the scope of the present invention, which is set forth in the appended claims. Various modifications of the above described embodiments can be made by those skilled in the art after reading this specification. All such modifications are within the scope and true spirit of the present invention.
Claims (3)
1. A method for transporting data, comprising:
packaging the data stored on a server into a plurality of data packets;
transmitting the plurality of data packets to a receiving proxy cache over a first link;
verifying a transmission status of the plurality of data packets at the receiving proxy cache; and
transmitting a data packet to the receiving proxy cache over a second link in response to the receiving proxy cache detecting a transmission error of the data packet.
2. A data transport system for transporting data between a server and a client receiver, comprising:
a memory device;
a data stream channel coupled between said memory device and a client receiver;
a first transmission link between the server and said memory device, said first transmission link being configured to transmit a plurality of data packets from the server to said memory device; and
a second transmission link between the server and said memory device, said second transmission link being configured to retransmit a data packet from the server to said memory device in response to said memory device detecting a transmission error associated with the data packet.
3. A process for transporting data from a server to a client receiver, comprising the steps of:
providing a receiving proxy cache coupled to a client receiver via a data stream channel;
packaging the data stored on the server into a plurality of data packets;
transmitting the plurality of data packets to the receiving proxy cache over a first link;
verifying a transmission status associated with each of the plurality of data packets at the receiving proxy cache;
transmitting a data packet to the receiving proxy cache over a second link in response to a transmission status associated with the data packet being in error; and
transporting the plurality of data packets received at the receiving proxy cache to a client receiver via a data stream channel.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/628,102 US20100077251A1 (en) | 2004-01-22 | 2009-11-30 | Method and system for reliably and efficiently transporting data over a network |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US53878804P | 2004-01-22 | 2004-01-22 | |
US11/041,079 US7643480B2 (en) | 2004-01-22 | 2005-01-21 | Method and system for reliably and efficiently transporting data over a network |
US12/628,102 US20100077251A1 (en) | 2004-01-22 | 2009-11-30 | Method and system for reliably and efficiently transporting data over a network |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/041,079 Continuation US7643480B2 (en) | 2004-01-22 | 2005-01-21 | Method and system for reliably and efficiently transporting data over a network |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100077251A1 true US20100077251A1 (en) | 2010-03-25 |
Family
ID=39542694
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/041,079 Active 2026-11-14 US7643480B2 (en) | 2004-01-22 | 2005-01-21 | Method and system for reliably and efficiently transporting data over a network |
US12/628,102 Abandoned US20100077251A1 (en) | 2004-01-22 | 2009-11-30 | Method and system for reliably and efficiently transporting data over a network |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/041,079 Active 2026-11-14 US7643480B2 (en) | 2004-01-22 | 2005-01-21 | Method and system for reliably and efficiently transporting data over a network |
Country Status (1)
Country | Link |
---|---|
US (2) | US7643480B2 (en) |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070254591A1 (en) * | 2006-05-01 | 2007-11-01 | Shary Nassimi | Wirefree Intercom Having Error Free Transmission System and Process |
US20080031149A1 (en) * | 2006-08-02 | 2008-02-07 | Silver Peak Systems, Inc. | Communications scheduler |
US20090164603A1 (en) * | 2005-04-07 | 2009-06-25 | Mediacast, Inc. | Adaptive file delivery system and method |
US20090182836A1 (en) * | 2008-01-16 | 2009-07-16 | Aviles Joaquin J | System and method for populating a cache using behavioral adaptive policies |
US20100274872A1 (en) * | 2005-04-07 | 2010-10-28 | Opanga Networks, Inc. | System and method for flow control in an adaptive file delivery system |
US20110258519A1 (en) * | 2008-12-03 | 2011-10-20 | Alcatel Lucent | Error Control On-Demand |
US20120269194A1 (en) * | 2011-04-20 | 2012-10-25 | Nec Corporation | Repeating device, communication system, communication method and recording medium for recording program |
US8929380B1 (en) | 2006-08-02 | 2015-01-06 | Silver Peak Systems, Inc. | Data matching using flow based packet data storage |
US9036662B1 (en) | 2005-09-29 | 2015-05-19 | Silver Peak Systems, Inc. | Compressing packet data |
US9092342B2 (en) | 2007-07-05 | 2015-07-28 | Silver Peak Systems, Inc. | Pre-fetching data into a memory |
US9130991B2 (en) | 2011-10-14 | 2015-09-08 | Silver Peak Systems, Inc. | Processing data packets in performance enhancing proxy (PEP) environment |
US9143455B1 (en) | 2008-07-03 | 2015-09-22 | Silver Peak Systems, Inc. | Quality of service using multiple flows |
US9152574B2 (en) | 2007-07-05 | 2015-10-06 | Silver Peak Systems, Inc. | Identification of non-sequential data stored in memory |
US9363248B1 (en) | 2005-08-12 | 2016-06-07 | Silver Peak Systems, Inc. | Data encryption in a network memory architecture for providing data based on local accessibility |
US9363309B2 (en) | 2005-09-29 | 2016-06-07 | Silver Peak Systems, Inc. | Systems and methods for compressing packet data by predicting subsequent data |
US9613071B1 (en) | 2007-11-30 | 2017-04-04 | Silver Peak Systems, Inc. | Deferred data storage |
US9626224B2 (en) | 2011-11-03 | 2017-04-18 | Silver Peak Systems, Inc. | Optimizing available computing resources within a virtual environment |
US9712463B1 (en) | 2005-09-29 | 2017-07-18 | Silver Peak Systems, Inc. | Workload optimization in a wide area network utilizing virtual switches |
US9717021B2 (en) | 2008-07-03 | 2017-07-25 | Silver Peak Systems, Inc. | Virtual network overlay |
US9753797B1 (en) * | 2011-08-26 | 2017-09-05 | Amazon Technologies, Inc. | Reliable intermediate multicast communications |
US9875344B1 (en) | 2014-09-05 | 2018-01-23 | Silver Peak Systems, Inc. | Dynamic monitoring and authorization of an optimization device |
US9948496B1 (en) | 2014-07-30 | 2018-04-17 | Silver Peak Systems, Inc. | Determining a transit appliance for data traffic to a software service |
US9967056B1 (en) | 2016-08-19 | 2018-05-08 | Silver Peak Systems, Inc. | Forward packet recovery with constrained overhead |
US10164861B2 (en) | 2015-12-28 | 2018-12-25 | Silver Peak Systems, Inc. | Dynamic monitoring and visualization for network health characteristics |
US10257082B2 (en) | 2017-02-06 | 2019-04-09 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows |
US10432484B2 (en) | 2016-06-13 | 2019-10-01 | Silver Peak Systems, Inc. | Aggregating select network traffic statistics |
US10637721B2 (en) | 2018-03-12 | 2020-04-28 | Silver Peak Systems, Inc. | Detecting path break conditions while minimizing network overhead |
US10771394B2 (en) | 2017-02-06 | 2020-09-08 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows on a first packet from DNS data |
US10805840B2 (en) | 2008-07-03 | 2020-10-13 | Silver Peak Systems, Inc. | Data transmission via a virtual wide area network overlay |
US10892978B2 (en) | 2017-02-06 | 2021-01-12 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows from first packet data |
US11044202B2 (en) | 2017-02-06 | 2021-06-22 | Silver Peak Systems, Inc. | Multi-level learning for predicting and classifying traffic flows from first packet data |
US11212210B2 (en) | 2017-09-21 | 2021-12-28 | Silver Peak Systems, Inc. | Selective route exporting using source type |
Families Citing this family (61)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6499060B1 (en) * | 1999-03-12 | 2002-12-24 | Microsoft Corporation | Media coding for loss recovery with remotely predicted data units |
AU2004247251B2 (en) * | 2003-06-12 | 2009-01-22 | Camiant, Inc. | PCMM application manager |
EP1631917B1 (en) * | 2003-06-12 | 2010-12-08 | Camiant, Inc. | Dynamic service delivery with topology discovery for communication networks |
US7643480B2 (en) * | 2004-01-22 | 2010-01-05 | Hain-Ching Liu | Method and system for reliably and efficiently transporting data over a network |
US20050188415A1 (en) * | 2004-01-23 | 2005-08-25 | Camiant, Inc. | Video policy server |
US20050175008A1 (en) * | 2004-02-06 | 2005-08-11 | Gordon Thompson | Method and system for replicating a video stream onto separate QAM downstream channels |
US7970020B2 (en) * | 2004-10-27 | 2011-06-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Terminal having plural playback pointers for jitter buffer |
US8634413B2 (en) | 2004-12-30 | 2014-01-21 | Microsoft Corporation | Use of frame caching to improve packet loss recovery |
US8364185B2 (en) * | 2005-04-18 | 2013-01-29 | Samsung Electronics Co., Ltd. | Method and system for synchronizing a clock for an adjacent network to a clock for an overlay network |
US7782767B1 (en) * | 2005-07-20 | 2010-08-24 | Tektronix, Inc. | Method and system for calculating burst bit rate for IP interactive applications |
US9491407B2 (en) * | 2006-01-17 | 2016-11-08 | At&T Intellectual Property I, L.P. | Method and system for integrating smart tags into a video data service |
JP5116319B2 (en) * | 2007-03-06 | 2013-01-09 | キヤノン株式会社 | Message relay apparatus and method |
US7760760B2 (en) * | 2007-11-28 | 2010-07-20 | Alcatel Lucent | Facilitating intelligent marking and discarding of MPEG video packets in IP packet stream |
US9113334B2 (en) * | 2008-02-01 | 2015-08-18 | Tekelec, Inc. | Methods, systems, and computer readable media for controlling access to voice resources in mobile networks using mobility management signaling messages |
FR2929789B1 (en) * | 2008-04-08 | 2010-04-30 | Canon Kk | METHOD FOR MANAGING MECHANISMS FOR IMPROVING TRANSMISSION OF DATA STREAMS ON TUNNEL, COMPUTER PROGRAM PRODUCT, CORRESPONDING STORAGE MEDIUM AND TUNNEL HEAD |
US8406254B2 (en) * | 2008-04-11 | 2013-03-26 | Mobitv, Inc. | Network optimized distribution |
US20090257447A1 (en) * | 2008-04-11 | 2009-10-15 | Mobitv, Inc. | Bit rate control |
JP2009284119A (en) * | 2008-05-21 | 2009-12-03 | Yokogawa Electric Corp | Field bus communication system and data management device |
US8194756B2 (en) * | 2008-05-28 | 2012-06-05 | Broadcom Corporation | Using program clock references to assist in transport of video stream to wireless device |
US7817631B1 (en) | 2008-07-09 | 2010-10-19 | Google Inc. | Network transfer protocol |
US8189623B2 (en) * | 2008-10-01 | 2012-05-29 | Infinera Corporation | Digital framer architecture with a framing marker |
FR2939993B1 (en) * | 2008-12-12 | 2010-12-17 | Canon Kk | METHOD FOR TRANSMITTING A MULTI-CHANNEL DATA STREAM ON A MULTI-TRANSPORT TUNNEL, COMPUTER PROGRAM PRODUCT, STORAGE MEDIUM, AND CORRESPONDING TUNNEL HEADS |
US20100153802A1 (en) * | 2008-12-15 | 2010-06-17 | At&T Corp. | System and Method for Anycast Transport Optimization |
US8161180B1 (en) * | 2008-12-18 | 2012-04-17 | Symantec Corporation | Method and apparatus for routing a data stream through a plurality of data movers independent of a network interface type |
US9769149B1 (en) * | 2009-07-02 | 2017-09-19 | Sonicwall Inc. | Proxy-less secure sockets layer (SSL) data inspection |
US9450804B2 (en) | 2009-09-03 | 2016-09-20 | At&T Intellectual Property I, L.P. | Anycast aware transport for content distribution networks |
JP2011061641A (en) * | 2009-09-14 | 2011-03-24 | Fuji Xerox Co Ltd | Device and system for transmitting image data signal |
WO2011040850A1 (en) | 2009-10-02 | 2011-04-07 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for retransmission using checksums for identifying lost data packets |
WO2011093836A1 (en) * | 2010-01-28 | 2011-08-04 | Thomson Licensing | A method and apparatus for retransmission decision making |
JP2013507826A (en) * | 2009-10-07 | 2013-03-04 | トムソン ライセンシング | Efficient application layer automatic retransmission request retransmission method for reliable real-time data streaming in networks |
FR2954029B1 (en) * | 2009-12-14 | 2012-07-13 | Canon Kk | METHOD FOR TRANSMITTING PACKETS OF A PASSENGER BIDIRECTIONAL DATA STREAM, MANAGER DEVICE, COMPUTER PROGRAM PRODUCT, AND CORRESPONDING STORAGE MEDIUM |
US8850053B2 (en) | 2010-04-08 | 2014-09-30 | At&T Intellectual Property I, L.P. | System and method for providing information to users of a communication network |
JP2012129868A (en) * | 2010-12-16 | 2012-07-05 | Nec Corp | Communication system |
EP2723031B1 (en) * | 2012-10-16 | 2019-07-24 | Robert Bosch Gmbh | Distributed measurement arrangement for an embedded automotive acquisition device with tcp acceleration |
US9413494B2 (en) * | 2013-01-17 | 2016-08-09 | Qualcomm Incorporated | FEC-based reliable transport control protocols for multipath streaming |
CA2903695A1 (en) | 2013-03-14 | 2014-10-02 | Rosemount Inc. | Communications unit for an industrial process network |
WO2015016919A1 (en) | 2013-07-31 | 2015-02-05 | Adaptive Spectrum And Signal Alignment, Inc. | Method and apparatus for continuous access network monitoring and packet loss estimation |
KR101884385B1 (en) * | 2014-01-31 | 2018-08-01 | 노키아 솔루션스 앤드 네트웍스 오와이 | Acknowledgement of a range of sequence numbers |
CN104917688A (en) * | 2014-03-12 | 2015-09-16 | 中国科学院声学研究所 | Code rate control method of streaming media gateway |
WO2015150737A1 (en) | 2014-03-31 | 2015-10-08 | British Telecommunications Public Limited Company | Multicast streaming |
US20170127147A1 (en) * | 2014-03-31 | 2017-05-04 | British Telecommunications Public Limited Company | Multicast streaming |
CN104579770A (en) * | 2014-12-30 | 2015-04-29 | 华为技术有限公司 | Method and device for managing data transmission channels |
US10498866B2 (en) * | 2015-02-10 | 2019-12-03 | Comcast Cable Communications, Llc | Methods and systems for delivering content |
US20160352832A1 (en) * | 2015-06-01 | 2016-12-01 | Alibaba Group Holding Limited | Enhancing data consistency in cloud storage system by entrance data buffering |
US10469899B2 (en) * | 2015-10-23 | 2019-11-05 | Avago Technologies International Sales Pte. Limited | Channel debonding of multiple tuners in different set top boxes |
US10255190B2 (en) * | 2015-12-17 | 2019-04-09 | Advanced Micro Devices, Inc. | Hybrid cache |
US20170324642A1 (en) * | 2016-05-04 | 2017-11-09 | Microsoft Technology Licensing, Llc | Initial and periodic slowdowns for background connections |
US11121818B2 (en) * | 2016-07-22 | 2021-09-14 | Peraso Technologies Inc. | Method and apparatus for unsolicited block acknowledgements |
KR102532645B1 (en) * | 2016-09-20 | 2023-05-15 | 삼성전자 주식회사 | Method and apparatus for providing data to streaming application in adaptive streaming service |
CN107294830B (en) * | 2017-06-19 | 2019-09-13 | 四川速宝网络科技有限公司 | A kind of data transmission method and system |
US11025691B1 (en) | 2017-11-22 | 2021-06-01 | Amazon Technologies, Inc. | Consuming fragments of time-associated data streams |
US10944804B1 (en) * | 2017-11-22 | 2021-03-09 | Amazon Technologies, Inc. | Fragmentation of time-associated data streams |
US10878028B1 (en) | 2017-11-22 | 2020-12-29 | Amazon Technologies, Inc. | Replicating and indexing fragments of time-associated data streams |
US10764347B1 (en) | 2017-11-22 | 2020-09-01 | Amazon Technologies, Inc. | Framework for time-associated data stream storage, processing, and replication |
CN111163120A (en) * | 2018-11-08 | 2020-05-15 | 阿里巴巴集团控股有限公司 | Data storage and transmission method and device of distributed database and storage medium |
CN111294405A (en) * | 2020-02-17 | 2020-06-16 | 北京北信源软件股份有限公司 | Proxy detection method and device |
CN111628847B (en) * | 2020-05-06 | 2022-04-08 | 上海幻电信息科技有限公司 | Data transmission method and device |
CN111818063A (en) * | 2020-07-10 | 2020-10-23 | 陕西领航软件技术有限公司 | Novel data transmission protocol for construction vehicle positioning equipment |
KR20220060326A (en) * | 2020-11-04 | 2022-05-11 | 삼성전자주식회사 | Interface circuit providing extension packet and processor inclduing the interface circuit |
US11962868B2 (en) * | 2020-11-30 | 2024-04-16 | Verizon Patent And Licensing Inc. | Detecting a quality issue associated with a video stream delivery |
CN114375019A (en) * | 2022-01-18 | 2022-04-19 | 北京智联安科技有限公司 | NB-IoT mobile state data retransmission method and system |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5867734A (en) * | 1994-11-21 | 1999-02-02 | Intel Corporation | Multiple-reader multiple-writer queue for a computer system |
US6678740B1 (en) * | 2000-01-14 | 2004-01-13 | Terayon Communication Systems, Inc. | Process carried out by a gateway in a home network to receive video-on-demand and other requested programs and services |
US20040120252A1 (en) * | 2002-12-20 | 2004-06-24 | International Business Machines Corporation | Flow control in network devices |
US20040221025A1 (en) * | 2003-04-29 | 2004-11-04 | Johnson Ted C. | Apparatus and method for monitoring computer networks |
US20050021821A1 (en) * | 2001-11-30 | 2005-01-27 | Turnbull Rory Stewart | Data transmission |
US6879599B1 (en) * | 2000-01-31 | 2005-04-12 | Telefonaktlebolaget Lm Ericsson (Publ) | Mapping of transcoder/rate adaptor unit protocols onto user datagram protocols |
US7043677B1 (en) * | 2001-07-19 | 2006-05-09 | Webex Communications, Inc. | Apparatus and method for separating corrupted data from non-corrupted data within a packet |
US7171491B1 (en) * | 2000-01-25 | 2007-01-30 | Cisco Technology, Inc. | Methods and apparatus for managing data distribution in a network |
US7643480B2 (en) * | 2004-01-22 | 2010-01-05 | Hain-Ching Liu | Method and system for reliably and efficiently transporting data over a network |
-
2005
- 2005-01-21 US US11/041,079 patent/US7643480B2/en active Active
-
2009
- 2009-11-30 US US12/628,102 patent/US20100077251A1/en not_active Abandoned
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5867734A (en) * | 1994-11-21 | 1999-02-02 | Intel Corporation | Multiple-reader multiple-writer queue for a computer system |
US6678740B1 (en) * | 2000-01-14 | 2004-01-13 | Terayon Communication Systems, Inc. | Process carried out by a gateway in a home network to receive video-on-demand and other requested programs and services |
US7171491B1 (en) * | 2000-01-25 | 2007-01-30 | Cisco Technology, Inc. | Methods and apparatus for managing data distribution in a network |
US6879599B1 (en) * | 2000-01-31 | 2005-04-12 | Telefonaktlebolaget Lm Ericsson (Publ) | Mapping of transcoder/rate adaptor unit protocols onto user datagram protocols |
US7043677B1 (en) * | 2001-07-19 | 2006-05-09 | Webex Communications, Inc. | Apparatus and method for separating corrupted data from non-corrupted data within a packet |
US20050021821A1 (en) * | 2001-11-30 | 2005-01-27 | Turnbull Rory Stewart | Data transmission |
US20040120252A1 (en) * | 2002-12-20 | 2004-06-24 | International Business Machines Corporation | Flow control in network devices |
US20040221025A1 (en) * | 2003-04-29 | 2004-11-04 | Johnson Ted C. | Apparatus and method for monitoring computer networks |
US7643480B2 (en) * | 2004-01-22 | 2010-01-05 | Hain-Ching Liu | Method and system for reliably and efficiently transporting data over a network |
Cited By (82)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8589508B2 (en) | 2005-04-07 | 2013-11-19 | Opanga Networks, Inc. | System and method for flow control in an adaptive file delivery system |
US8583820B2 (en) * | 2005-04-07 | 2013-11-12 | Opanga Networks, Inc. | System and method for congestion detection in an adaptive file delivery system |
US8832305B2 (en) | 2005-04-07 | 2014-09-09 | Opanga Networks, Inc. | System and method for delivery of secondary data files |
US8589585B2 (en) | 2005-04-07 | 2013-11-19 | Opanga Networks, Inc. | Adaptive file delivery system and method |
US20090254675A1 (en) * | 2005-04-07 | 2009-10-08 | Mediacast, Inc. | Adaptive file delivery system and method |
US20100161679A1 (en) * | 2005-04-07 | 2010-06-24 | Mediacast, Inc. | System and method for delivery of secondary data files |
US20100161387A1 (en) * | 2005-04-07 | 2010-06-24 | Mediacast, Inc. | System and method for delivery of data files using service provider networks |
US20100274872A1 (en) * | 2005-04-07 | 2010-10-28 | Opanga Networks, Inc. | System and method for flow control in an adaptive file delivery system |
US20100274871A1 (en) * | 2005-04-07 | 2010-10-28 | Opanga Networks, Inc. | System and method for congestion detection in an adaptive file delivery system |
US8812722B2 (en) | 2005-04-07 | 2014-08-19 | Opanga Networks, Inc. | Adaptive file delivery system and method |
US8671203B2 (en) | 2005-04-07 | 2014-03-11 | Opanga, Inc. | System and method for delivery of data files using service provider networks |
US20090164603A1 (en) * | 2005-04-07 | 2009-06-25 | Mediacast, Inc. | Adaptive file delivery system and method |
US10091172B1 (en) | 2005-08-12 | 2018-10-02 | Silver Peak Systems, Inc. | Data encryption in a network memory architecture for providing data based on local accessibility |
US9363248B1 (en) | 2005-08-12 | 2016-06-07 | Silver Peak Systems, Inc. | Data encryption in a network memory architecture for providing data based on local accessibility |
US9549048B1 (en) | 2005-09-29 | 2017-01-17 | Silver Peak Systems, Inc. | Transferring compressed packet data over a network |
US9363309B2 (en) | 2005-09-29 | 2016-06-07 | Silver Peak Systems, Inc. | Systems and methods for compressing packet data by predicting subsequent data |
US9712463B1 (en) | 2005-09-29 | 2017-07-18 | Silver Peak Systems, Inc. | Workload optimization in a wide area network utilizing virtual switches |
US9036662B1 (en) | 2005-09-29 | 2015-05-19 | Silver Peak Systems, Inc. | Compressing packet data |
US20070254591A1 (en) * | 2006-05-01 | 2007-11-01 | Shary Nassimi | Wirefree Intercom Having Error Free Transmission System and Process |
US20110096817A1 (en) * | 2006-05-01 | 2011-04-28 | The Chamberlain Group, Inc. | Wirefree Intercom Having Error Free Transmission System And Process |
US7869823B2 (en) * | 2006-05-01 | 2011-01-11 | The Chamberlain Group, Inc. | Wirefree intercom having error free transmission system and process |
US8885632B2 (en) * | 2006-08-02 | 2014-11-11 | Silver Peak Systems, Inc. | Communications scheduler |
US9584403B2 (en) | 2006-08-02 | 2017-02-28 | Silver Peak Systems, Inc. | Communications scheduler |
US8929380B1 (en) | 2006-08-02 | 2015-01-06 | Silver Peak Systems, Inc. | Data matching using flow based packet data storage |
US20080031149A1 (en) * | 2006-08-02 | 2008-02-07 | Silver Peak Systems, Inc. | Communications scheduler |
US9961010B2 (en) | 2006-08-02 | 2018-05-01 | Silver Peak Systems, Inc. | Communications scheduler |
US9191342B2 (en) | 2006-08-02 | 2015-11-17 | Silver Peak Systems, Inc. | Data matching using flow based packet data storage |
US9438538B2 (en) | 2006-08-02 | 2016-09-06 | Silver Peak Systems, Inc. | Data matching using flow based packet data storage |
US9092342B2 (en) | 2007-07-05 | 2015-07-28 | Silver Peak Systems, Inc. | Pre-fetching data into a memory |
US9253277B2 (en) | 2007-07-05 | 2016-02-02 | Silver Peak Systems, Inc. | Pre-fetching stored data from a memory |
US9152574B2 (en) | 2007-07-05 | 2015-10-06 | Silver Peak Systems, Inc. | Identification of non-sequential data stored in memory |
US9613071B1 (en) | 2007-11-30 | 2017-04-04 | Silver Peak Systems, Inc. | Deferred data storage |
US20140310373A1 (en) * | 2008-01-16 | 2014-10-16 | Netapp, Inc. | System and method for populating a cache using behavioral adaptive policies |
US8805949B2 (en) * | 2008-01-16 | 2014-08-12 | Netapp, Inc. | System and method for populating a cache using behavioral adaptive policies |
US9426247B2 (en) * | 2008-01-16 | 2016-08-23 | Netapp, Inc. | System and method for populating a cache using behavioral adaptive policies |
US20090182836A1 (en) * | 2008-01-16 | 2009-07-16 | Aviles Joaquin J | System and method for populating a cache using behavioral adaptive policies |
US9717021B2 (en) | 2008-07-03 | 2017-07-25 | Silver Peak Systems, Inc. | Virtual network overlay |
US9397951B1 (en) | 2008-07-03 | 2016-07-19 | Silver Peak Systems, Inc. | Quality of service using multiple flows |
US9143455B1 (en) | 2008-07-03 | 2015-09-22 | Silver Peak Systems, Inc. | Quality of service using multiple flows |
US11419011B2 (en) | 2008-07-03 | 2022-08-16 | Hewlett Packard Enterprise Development Lp | Data transmission via bonded tunnels of a virtual wide area network overlay with error correction |
US11412416B2 (en) | 2008-07-03 | 2022-08-09 | Hewlett Packard Enterprise Development Lp | Data transmission via bonded tunnels of a virtual wide area network overlay |
US10805840B2 (en) | 2008-07-03 | 2020-10-13 | Silver Peak Systems, Inc. | Data transmission via a virtual wide area network overlay |
US10313930B2 (en) | 2008-07-03 | 2019-06-04 | Silver Peak Systems, Inc. | Virtual wide area network overlays |
US20110258519A1 (en) * | 2008-12-03 | 2011-10-20 | Alcatel Lucent | Error Control On-Demand |
US8677220B2 (en) * | 2008-12-03 | 2014-03-18 | Alcatel Lucent | Error control on-demand |
US20120269194A1 (en) * | 2011-04-20 | 2012-10-25 | Nec Corporation | Repeating device, communication system, communication method and recording medium for recording program |
US9753797B1 (en) * | 2011-08-26 | 2017-09-05 | Amazon Technologies, Inc. | Reliable intermediate multicast communications |
US9130991B2 (en) | 2011-10-14 | 2015-09-08 | Silver Peak Systems, Inc. | Processing data packets in performance enhancing proxy (PEP) environment |
US9906630B2 (en) | 2011-10-14 | 2018-02-27 | Silver Peak Systems, Inc. | Processing data packets in performance enhancing proxy (PEP) environment |
US9626224B2 (en) | 2011-11-03 | 2017-04-18 | Silver Peak Systems, Inc. | Optimizing available computing resources within a virtual environment |
US9948496B1 (en) | 2014-07-30 | 2018-04-17 | Silver Peak Systems, Inc. | Determining a transit appliance for data traffic to a software service |
US11374845B2 (en) | 2014-07-30 | 2022-06-28 | Hewlett Packard Enterprise Development Lp | Determining a transit appliance for data traffic to a software service |
US11381493B2 (en) | 2014-07-30 | 2022-07-05 | Hewlett Packard Enterprise Development Lp | Determining a transit appliance for data traffic to a software service |
US10812361B2 (en) | 2014-07-30 | 2020-10-20 | Silver Peak Systems, Inc. | Determining a transit appliance for data traffic to a software service |
US9875344B1 (en) | 2014-09-05 | 2018-01-23 | Silver Peak Systems, Inc. | Dynamic monitoring and authorization of an optimization device |
US10719588B2 (en) | 2014-09-05 | 2020-07-21 | Silver Peak Systems, Inc. | Dynamic monitoring and authorization of an optimization device |
US11868449B2 (en) | 2014-09-05 | 2024-01-09 | Hewlett Packard Enterprise Development Lp | Dynamic monitoring and authorization of an optimization device |
US11921827B2 (en) | 2014-09-05 | 2024-03-05 | Hewlett Packard Enterprise Development Lp | Dynamic monitoring and authorization of an optimization device |
US10885156B2 (en) | 2014-09-05 | 2021-01-05 | Silver Peak Systems, Inc. | Dynamic monitoring and authorization of an optimization device |
US11954184B2 (en) | 2014-09-05 | 2024-04-09 | Hewlett Packard Enterprise Development Lp | Dynamic monitoring and authorization of an optimization device |
US10771370B2 (en) | 2015-12-28 | 2020-09-08 | Silver Peak Systems, Inc. | Dynamic monitoring and visualization for network health characteristics |
US10164861B2 (en) | 2015-12-28 | 2018-12-25 | Silver Peak Systems, Inc. | Dynamic monitoring and visualization for network health characteristics |
US11336553B2 (en) | 2015-12-28 | 2022-05-17 | Hewlett Packard Enterprise Development Lp | Dynamic monitoring and visualization for network health characteristics of network device pairs |
US10432484B2 (en) | 2016-06-13 | 2019-10-01 | Silver Peak Systems, Inc. | Aggregating select network traffic statistics |
US11601351B2 (en) | 2016-06-13 | 2023-03-07 | Hewlett Packard Enterprise Development Lp | Aggregation of select network traffic statistics |
US11757740B2 (en) | 2016-06-13 | 2023-09-12 | Hewlett Packard Enterprise Development Lp | Aggregation of select network traffic statistics |
US11757739B2 (en) | 2016-06-13 | 2023-09-12 | Hewlett Packard Enterprise Development Lp | Aggregation of select network traffic statistics |
US10848268B2 (en) | 2016-08-19 | 2020-11-24 | Silver Peak Systems, Inc. | Forward packet recovery with constrained network overhead |
US10326551B2 (en) | 2016-08-19 | 2019-06-18 | Silver Peak Systems, Inc. | Forward packet recovery with constrained network overhead |
US9967056B1 (en) | 2016-08-19 | 2018-05-08 | Silver Peak Systems, Inc. | Forward packet recovery with constrained overhead |
US11424857B2 (en) | 2016-08-19 | 2022-08-23 | Hewlett Packard Enterprise Development Lp | Forward packet recovery with constrained network overhead |
US10771394B2 (en) | 2017-02-06 | 2020-09-08 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows on a first packet from DNS data |
US11044202B2 (en) | 2017-02-06 | 2021-06-22 | Silver Peak Systems, Inc. | Multi-level learning for predicting and classifying traffic flows from first packet data |
US11582157B2 (en) | 2017-02-06 | 2023-02-14 | Hewlett Packard Enterprise Development Lp | Multi-level learning for classifying traffic flows on a first packet from DNS response data |
US10257082B2 (en) | 2017-02-06 | 2019-04-09 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows |
US11729090B2 (en) | 2017-02-06 | 2023-08-15 | Hewlett Packard Enterprise Development Lp | Multi-level learning for classifying network traffic flows from first packet data |
US10892978B2 (en) | 2017-02-06 | 2021-01-12 | Silver Peak Systems, Inc. | Multi-level learning for classifying traffic flows from first packet data |
US11212210B2 (en) | 2017-09-21 | 2021-12-28 | Silver Peak Systems, Inc. | Selective route exporting using source type |
US11805045B2 (en) | 2017-09-21 | 2023-10-31 | Hewlett Packard Enterprise Development Lp | Selective routing |
US10637721B2 (en) | 2018-03-12 | 2020-04-28 | Silver Peak Systems, Inc. | Detecting path break conditions while minimizing network overhead |
US10887159B2 (en) | 2018-03-12 | 2021-01-05 | Silver Peak Systems, Inc. | Methods and systems for detecting path break conditions while minimizing network overhead |
US11405265B2 (en) | 2018-03-12 | 2022-08-02 | Hewlett Packard Enterprise Development Lp | Methods and systems for detecting path break conditions while minimizing network overhead |
Also Published As
Publication number | Publication date |
---|---|
US7643480B2 (en) | 2010-01-05 |
US20080151881A1 (en) | 2008-06-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7643480B2 (en) | Method and system for reliably and efficiently transporting data over a network | |
US7522528B2 (en) | Low-latency automatic repeat request packet recovery mechanism for media streams | |
US6694471B1 (en) | System and method for periodic retransmission of messages | |
CN111740808B (en) | Data transmission method and device | |
JP4623616B2 (en) | Data transmission method and apparatus | |
US8306058B2 (en) | Communication system and techniques for transmission from source to destination | |
US7380014B2 (en) | Reliable real-time transport protocol | |
EP1397899B1 (en) | Real-time packetization and retransmission in streaming applications | |
EP2090038B1 (en) | Method, device and software application for scheduling the transmission of data system packets | |
US20040098748A1 (en) | MPEG-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control | |
US11949512B2 (en) | Retransmission of data in packet networks | |
EP1301041A1 (en) | Video data transmission method and apparatus | |
CA2846546C (en) | Cable modem termination system control of cable modem queue length | |
BRPI0722125B1 (en) | METHOD, SYSTEM AND APPLIANCE FOR CORRECTION OF ADAPTIVE FORWARDING ERROR WITH COMBINED AUTOMATIC REPEAT REQUEST FOR RELIABLE MULTITRANSMISSION IN WIRELESS LOCAL AREA NETWORKS | |
US9781488B2 (en) | Controlled adaptive rate switching system and method for media streaming over IP networks | |
CN101939967A (en) | Communications method | |
Natarajan et al. | Non-renegable selective acknowledgments (NR-SACKs) for SCTP | |
EP1450535A1 (en) | A relay for hierarchical retransmissions in multimedia streaming | |
JP3848222B2 (en) | Resending method | |
Wei et al. | QoS tradeoffs using an application-oriented transport protocol (AOTP) for multimedia applications over IP | |
Huszák et al. | TFRC-Based Selective Retransmission for Multimedia Applications. | |
Arefin et al. | Modified SACK-TCP and some application level techniques to support real-time application | |
CN116827920A (en) | Weak network transmission method, system, equipment and medium of streaming media server | |
JP2003198612A (en) | File transferring method in packet communication network | |
Huang et al. | An unreliable concurrent multipath transfer protocol over multihomed networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SOFTWARE SITE APPLICATIONS, LIMITED LIABILITY COMP Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EXAVIO LLC;REEL/FRAME:023585/0247 Effective date: 20080605 |
|
AS | Assignment |
Owner name: INTELLECTUAL VENTURES I LLC, DELAWARE Free format text: MERGER;ASSIGNOR:SOFTWARE SITE APPLICATIONS, LIMITED LIABILITY COMPANY;REEL/FRAME:030744/0364 Effective date: 20130705 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |