Browse Prior Art Database

A Method to Improve Retransmission of Data via Single, Sequential Query and Multi-cast Data Retransmits.

IP.com Disclosure Number: IPCOM000015774D
Original Publication Date: 2002-Oct-26
Included in the Prior Art Database: 2003-Jun-21
Document File: 2 page(s) / 41K

Publishing Venue

IBM

Abstract

A Method to Improve Retransmission of Data via Single, Sequential Query and Multi-cast Data Retransmits. Lost data packets in complex data broadcasts are a common occurrence, especially on busy networks. Typically, when a transmission occurs during a handshake, the transmitter waits for the receiver to acknowledge the transmission. During this acknowledgement, the transmitter learns if any portion of the data stream didn't make it and needs to be retransmitted. Lost data typically occurs due to packet collisions, physical outages, and network overload (the packet is not lost, just stuck behind other traffic but considered lost due to timeouts). For single systems, this is an easy situation where the data that didn't make it is retransmitted by the sender. However, there are cases where the sender is broadcasting a common data stream to multiple clients that are all waiting in parallel. The chances that each of these clients experienced the same success or failure during the transmission is extremely low. In fact (let's say there are 100 clients waiting for a parallel stream of data), it is most likely that all the clients experienced some data incompleteness, but it's different for each client. It's also fair to say that there may possibly be some clients that are also missing the same piece of data (the same network problem occurred to them at the same time, for example).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

A Method to Improve Retransmission of Data via Single, Sequential Query and

Multi-cast Data Retransmits.

Lost data packets in complex data broadcasts are a common occurrence, especially on busy networks. Typically, when a transmission occurs during a handshake, the transmitter waits for the receiver to acknowledge the transmission. During this acknowledgement, the transmitter learns if any portion of the data stream didn't make it and needs to be retransmitted. Lost data typically occurs due to packet collisions, physical outages, and network overload (the packet is not lost, just stuck behind other traffic - but considered lost due to timeouts). For single systems, this is an easy situation where the data that didn't make it is retransmitted by the sender.

However, there are cases where the sender is broadcasting a common data stream to multiple clients that are all waiting in parallel. The chances that each of these clients experienced the same success or failure during the transmission is extremely low. In fact (let's say there are 100 clients waiting for a parallel stream of data), it is most likely that all the clients experienced some data incompleteness, but it's different for each client. It's also fair to say that there may possibly be some clients that are also missing the same piece of data (the same network problem occurred to them at the same time, for example).

This proposal is a method to improve the recovery procedure of the retransmit process so that all the clients get the complete data stream faster. What is proposed is that, after the initial multi-cast transmission of data is complete, the transmitter queries each client in a sequential manner, but does the re-broadcast in a multicast way.

For example, suppose there are 10 client machines. After a large data stream transmission of 100 MB (done in parallel to all 10 machines), the transmitter now goes to client 1 and asks this first client what portions of the 100MB are...